I've updated it with my comments.
Since the system is written in itself (and runs inside itself), there are several things in the PP that require redesigning very large parts of the system. We need at least one VM hacker on this list to evaluate the feasability of some of the needed changes.
Note: The current wiki system is probably not going to be sufficient for long-term usage. Part of the EAL that we need to meet includes positive authorized user identification for all changes to the configuration... and since documentation (and an audit trail and history) will be a major part of proving our case to the assurance labs, I'm thinking that we should treat it as part of the configuration. We'll need individual usernames and passwords for the modifications until we get X.509/PKI up and running, then we'll possibly be able to use PK crypto certificates for authentication.
I'll leave it up to Krishna to determine the actual policy and implementation, since he's got formal validation experience. I just know what I've read in the CC PDFs and the single-layer OS/moderate environment document, and I'm interpreting it in the most secure (and most trust-pessimistic) manner that I can.
Here's hoping that we get at least one validation out of this in the end. :)
-Kyle H
On 10/17/06, Krishna Sankar ksankar@doubleclix.net wrote:
Have started to put the task list and notes in our cryptography Wiki page at http://minnow.cc.gatech.edu/squeak/5776.
For now, the cc information is at the end of the cryptography page. As we add more details and get a fix on the organization, we can start a set of new pages.
Kyle, can you pl add your notes and observations ? Thanks.
Cheers
<k/>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Krishna Sankar Sent: Tuesday, October 17, 2006 9:46 AM To: Ron@USMedRec.com; 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Common Criteria Documentation...
http://code.google.com/p/squeak-cc-validation/ = Validation documentation, plan and test results, bug tracking. This
should not
hold code.
<KS>
I would prefer to hold the validation documentation,plan and test results in a Wiki. That way we have built-in revision control as well as history tracking. In that sense the Google projects do not help us.
The bug tracking in Google projects is fine.</KS>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On
Behalf Of
Ron Teitelbaum Sent: Tuesday, October 17, 2006 9:34 AM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Common Criteria Documentation...
I thought the idea was to us SVN for those documents? If more is needed let's just use the wiki that is part of www.squeaksource.com/Cryptography
It's not a full wiki in that it doesn't appear to support
file uploads
but that what I thought the google source was for.
Can we map out what our requirements are and what our current resources are for meeting those requirements, then we can
look at what
more we need.
What I see is:
www.squeaksoruce.com/Cryptography = Code Repository and limited wiki
http://code.google.com/p/squeak-cc-validation/ = Validation documentation, plan and test results, bug tracking. This
should not
hold code.
cryptography@lists.squeakfoundation.org is our mailing list.
Ron
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On
Behalf Of
Krishna Sankar Sent: Tuesday, October 17, 2006 11:11 AM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Common Criteria Documentation...
Kyle,
Can you see if you have the SVN write access ? All, Just as FYI, we need gmail address to become part of the Google project and it has no Wiki. Any thoughts on the Wiki for us to document the functionalities and the results of
development/testing ?
Cheers
<k/>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org]
On Behalf
Of Kyle Hamilton Sent: Monday, October 16, 2006 8:33 PM To: Cryptography Team Development List Subject: [Cryptography Team] Common Criteria Documentation...
I found the Google Code project that Krishna started, and
uploaded
the Common Criteria documentation I found (in PDF form) to it as an issue. Unfortunately, I don't have SVN write access, and I
don't know how
to get it either.
After reading it, I realized that it /IS/ a good idea
for anyone
starting on CC validation to read it before they start. It's important to realize what it is, and what the goals
must be. (As
well, it also helps customers -- that'd include you, Ron -- understand what the various validation levels are, and
compare them
to regulatory requirement.)
--
-Kyle H I speak only for myself. I don't have the faintest clue about anyone else. _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry ptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
y
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
ptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
ptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Hi Kyle--
Since the system is written in itself (and runs inside itself), there are several things in the PP that require redesigning very large parts of the system. We need at least one VM hacker on this list to evaluate the feasability of some of the needed changes.
I can do that.
thanks!
-C
Very cool thanks Craig!
Ron
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Craig Latta Sent: Tuesday, October 17, 2006 8:33 PM To: Cryptography Team Development List Subject: [Cryptography Team] re: Common Criteria Documentation...
Hi Kyle--
Since the system is written in itself (and runs inside itself), there are several things in the PP that require redesigning very large parts of the system. We need at least one VM hacker on this list to evaluate the feasability of some of the needed changes.
I can do that. thanks!-C
-- Craig Latta http://netjam.org/resume
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Thank you, Craig.
If you look at the bottom of the Cryptography page on the minnow/squeak wiki, you'll see what I mean by "serious redesign". I'll go through the EAL documentation and the PP, and see what else isn't currently implemented but needs to be. (I hope that someone else can and will, too, since this is going to require something close to actuarial skills. I'm good with details, but I sometimes get so tangled in them that I forget something important.)
But, that brings this up: this list is about cryptography, but our direction is (eventually, as stated by Krishna) CC EAL 4+ validation. This requires FIPS-validated cryptographic software, but there's a lot more to it than that. Are we going to split efforts between cryptography/FIPS and the remainder of the CC validation, and maybe do it more quickly? Are we going to focus on FIPS first, and only after we get something that we can submit for validation then worry about the remainder for CC?
-Kyle H
On 10/17/06, Craig Latta craig@netjam.org wrote:
Hi Kyle--
Since the system is written in itself (and runs inside itself), there are several things in the PP that require redesigning very large parts of the system. We need at least one VM hacker on this list to evaluate the feasability of some of the needed changes.
I can do that. thanks!-C
-- Craig Latta http://netjam.org/resume
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
there's a lot more to it than that. Are we going to split efforts between cryptography/FIPS and the remainder of the CC validation, and maybe do it more quickly? Are we going to focus on FIPS first, and only after we get something that we can submit for validation then worry about the remainder for CC?
<KS> Yep, good thoughts. As you correctly point out, first we should aim for the smallest subset possible; after a successful validation, we can extend it. That way we get our infrastructure in place, the processes ironed out and get overall experience. We still will have to address some of the fundamental issues, but hopefully they are manageable.
In the commercial world, with a product like a firewall or a router, there is no such luxury - the whole product need to be validated and in a short period of time.
And as Ron points out, the authenticated site et al can come after we go thru a dry run. We should still keep a track of the activities, results et al, but not in a strict authenticated way until we have all the ducks in a row.
One important aspect we need to think about now is this minimal subset - and what it should consist of and what it should achieve.
I will also read thru, understand the current environment and think thru the paces. If we can get the cryptography engine certified, it will be a win. Am not sure it can be done separately, though.
</KS>
Cheers <k/>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Kyle Hamilton Sent: Tuesday, October 17, 2006 6:09 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] re: Common Criteria Documentation...
Thank you, Craig.
If you look at the bottom of the Cryptography page on the minnow/squeak wiki, you'll see what I mean by "serious redesign". I'll go through the EAL documentation and the PP, and see what else isn't currently implemented but needs to be. (I hope that someone else can and will, too, since this is going to require something close to actuarial skills. I'm good with details, but I sometimes get so tangled in them that I forget something important.)
But, that brings this up: this list is about cryptography, but our direction is (eventually, as stated by Krishna) CC EAL 4+ validation. This requires FIPS-validated cryptographic software, but there's a lot more to it than that. Are we going to split efforts between cryptography/FIPS and the remainder of the CC validation, and maybe do it more quickly? Are we going to focus on FIPS first, and only after we get something that we can submit for validation then worry about the remainder for CC?
-Kyle H
On 10/17/06, Craig Latta craig@netjam.org wrote:
Hi Kyle--
Since the system is written in itself (and runs inside itself), there are several things in the PP that require redesigning very large parts of the system. We need at least one VM
hacker on this
list to evaluate the feasability of some of the needed changes.
I can do that. thanks!-C
-- Craig Latta http://netjam.org/resume
Cryptography mailing list Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
y
--
-Kyle H _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
ptography
Kyle,
Just to be clear, incase I'm missing something. My understanding is that there is a large amount of work that needs to be done to show that we meet the criteria. My interest right now is the tasks that need to be performed prior to an actual validation. If we decide on a platform and then run through the validation tasks we can identify the holes in our system that still need developing. We don't need an actual secure platform to do the validation until we are sure that we can pass the validation. At that point we can start working on setting up an actual implementation for a lab to scrutinize.
In my opinion we should be considering this pre-validation research, which means we can loosen the actual requirements as long as we believe that we can meet those requirements when the time comes to move to the next phase.
Does that make sense or am I missing something?
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Kyle Hamilton Sent: Tuesday, October 17, 2006 8:08 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] Common Criteria Documentation...
I've updated it with my comments.
Since the system is written in itself (and runs inside itself), there are several things in the PP that require redesigning very large parts of the system. We need at least one VM hacker on this list to evaluate the feasability of some of the needed changes.
Note: The current wiki system is probably not going to be sufficient for long-term usage. Part of the EAL that we need to meet includes positive authorized user identification for all changes to the configuration... and since documentation (and an audit trail and history) will be a major part of proving our case to the assurance labs, I'm thinking that we should treat it as part of the configuration. We'll need individual usernames and passwords for the modifications until we get X.509/PKI up and running, then we'll possibly be able to use PK crypto certificates for authentication.
I'll leave it up to Krishna to determine the actual policy and implementation, since he's got formal validation experience. I just know what I've read in the CC PDFs and the single-layer OS/moderate environment document, and I'm interpreting it in the most secure (and most trust-pessimistic) manner that I can.
Here's hoping that we get at least one validation out of this in the end. :)
-Kyle H
On 10/17/06, Krishna Sankar ksankar@doubleclix.net wrote:
Have started to put the task list and notes in our cryptography Wiki
page at
http://minnow.cc.gatech.edu/squeak/5776.
For now, the cc information is at the end of the cryptography page. As
we
add more details and get a fix on the organization, we can start a set
of
new pages.
Kyle, can you pl add your notes and observations ? Thanks.
Cheers
<k/>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Krishna Sankar Sent: Tuesday, October 17, 2006 9:46 AM To: Ron@USMedRec.com; 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Common Criteria Documentation...
http://code.google.com/p/squeak-cc-validation/ = Validation documentation, plan and test results, bug tracking. This
should not
hold code.
<KS>
I would prefer to hold the validation documentation,plan and test results in a Wiki. That way we have built-in revision control as well as history tracking. In that sense the Google projects do not help us.
The bug tracking in Google projects is fine.</KS>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On
Behalf Of
Ron Teitelbaum Sent: Tuesday, October 17, 2006 9:34 AM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Common Criteria Documentation...
I thought the idea was to us SVN for those documents? If more is needed let's just use the wiki that is part of www.squeaksource.com/Cryptography
It's not a full wiki in that it doesn't appear to support
file uploads
but that what I thought the google source was for.
Can we map out what our requirements are and what our current resources are for meeting those requirements, then we can
look at what
more we need.
What I see is:
www.squeaksoruce.com/Cryptography = Code Repository and limited wiki
http://code.google.com/p/squeak-cc-validation/ = Validation documentation, plan and test results, bug tracking. This
should not
hold code.
cryptography@lists.squeakfoundation.org is our mailing list.
Ron
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On
Behalf Of
Krishna Sankar Sent: Tuesday, October 17, 2006 11:11 AM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Common Criteria Documentation...
Kyle,
Can you see if you have the SVN write access ? All, Just as FYI, we need gmail address to become part of the Google project and it has no Wiki. Any thoughts on the Wiki for us to document the functionalities and the results of
development/testing ?
Cheers
<k/>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org]
On Behalf
Of Kyle Hamilton Sent: Monday, October 16, 2006 8:33 PM To: Cryptography Team Development List Subject: [Cryptography Team] Common Criteria Documentation...
I found the Google Code project that Krishna started, and
uploaded
the Common Criteria documentation I found (in PDF form) to it as an issue. Unfortunately, I don't have SVN write access, and I
don't know how
to get it either.
After reading it, I realized that it /IS/ a good idea
for anyone
starting on CC validation to read it before they start. It's important to realize what it is, and what the goals
must be. (As
well, it also helps customers -- that'd include you, Ron -- understand what the various validation levels are, and
compare them
to regulatory requirement.)
--
-Kyle H I speak only for myself. I don't have the faintest clue about anyone else. _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry ptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
y
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
ptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
ptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
--
-Kyle H _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Ron,
'large number of tasks' is an understatement. :) The question is this: which validation are you looking for, first? Two (well, three, really, but only two classes of) validations have been mentioned, and my question relates to which of them resources will be allocated to -- which, in turn, defines what should go on the task list and with what priority.
FIPS 140-2 is the Trusted Cryptographic Module, which in and of itself is a huge undertaking -- a high-level overview of the things required for it are "make sure that the binary representation of the code cannot be altered", "make sure that calls into the binary representation of the code cannot be diverted", "make sure that, once in FIPS mode, only FIPS-approved algorithms can be used", "ensure that the random number generator has a good enough source of entropy AND is then stirred by a FIPS-approved pseudo-random function", and various and sundry other things. This is the validation that OpenSSL received, this is the validation that Windows CryptoAPI received, this is the validation that those two specific binary versions of Crypto++ received, this is the mandatory validation for cryptographic software that is to be used by the US government. (VM changes will be required for a validatable pure-Squeak FIPS implementation.)
Common Criteria assurance validation is mandatory for entire systems that are to be used by the US government, and for information processing systems used by financial institutions. It also provides (to my understanding) assurance that is good enough for HIPAA's requirements. One of its requirements is that it use FIPS-validated cryptographic software, but it doesn't stop there -- this validation applies to entire systems and not merely the cryptographic component. In any case, the project eventually will need a FIPS-validated cryptographic component in its architecture, be it through using a platform-native library, a smart-card interface, or a pure-Squeak component. (VM changes will also be needed for this validation.)
You can loosen the requirements now, as long as an eye is kept on the long view. If the system is mis-architected, it will require substantial rebuilding of the VM to bring it into validatable conformance with either the Common Criteria or FIPS. This is the reason why I felt that we should bring in a VM hacker now -- as it stands there is no way that, even plugging in an external FIPS library, the system could meet anything but the most basic assurance. This is going to be a long-term, many-component project, and I don't envy Krishna the management of it nor you the executive role. The least that I and anyone else can do is help you manage it. This includes making sure that every team knows at the outset what the eventual parameters will be, so no one codes themselves into a corner.
A problem exists with loosening the documentation requirements for too long -- which is that if it is left for too long, the criteria simply cannot be met. Krishna suggested a Protection Profile as a target ("Single-Level Operating Systems in Medium Robustness Environments PP") which requires that the system must meet EAL 4 with some augmentations. In order to do that, there are some requirements, including partially-automated configuration management (I'm thinking that Monticello may be good enough for this, though I have not looked at it or the CC in sufficient detail to be able to state definitively), that require that only authorized changes can be made to any configuration item.
I quote paragraph 217 from the Common Criteria v2.3 Part 3 document:
217 EAL4 also provides assurance through the use of development environment controls and additional TOE configuration management including automation, and evidence of secure delivery procedures.
All of the relevant information is contained in the CC v2.3 documentation (the administrative requirements are contained in part 3). Suffice it to say, though, that one of the requirements is that no developer should be able to insert unauthorized or malicious code or information undetected -- and since the profile includes that Administrator and User documentation will be created and delivered, those documents must be kept under Configuration Management as well.
If a wiki is used to write and edit those documents, that wiki must be able to ensure that only authorized people can modify them. It must also be able to backtrack the various changes to find when any given piece was added, removed, or altered, and who did the alteration of the documentation at that time.
I apologize for the length of this, but I do want to ensure that everyone is on the same page and understands the rationale behind some of my statements. You and/or Krishna are going to make decisions as to the exact procedures that the team and project are going to use -- however, I'm an agoraphobic bachelor, and I thus have more time to research the requirements much more in-depth than you two can. This suggests that I should do so, and make recommendations based on what I have found.
I liken this to the role of a research librarian -- sift through mountains of data, to provide a concise report. As I said, I defer to you and Krishna -- but if you want to know the rationale behind something I suggest, I will quote you book, chapter and paragraph of everything relevant that I have found so that you can make up your own minds without having to sift through the mountains yourselves.
So, to sum it all up: One of the tasks that needs to be completed is to set up an authenticated configuration management system before the user and administrator documentation is written. As I said, the current wiki system will not be sufficient for the long term, but there's a huge mountain of other tasks as well. Since no administrator or user documentation is being created at this point, the wiki does not need to move to a positive identification system yet. Not in the short term, and probably not in the medium term. This doesn't mean that the eventual need shouldn't be planned for.
(Arguably, design documents and implementation plans should also be entered into CM. Again, though, this is a long-term project, and rough ideas probably don't.)
-Kyle H
On 10/17/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Kyle,
Just to be clear, incase I'm missing something. My understanding is that there is a large amount of work that needs to be done to show that we meet the criteria. My interest right now is the tasks that need to be performed prior to an actual validation. If we decide on a platform and then run through the validation tasks we can identify the holes in our system that still need developing. We don't need an actual secure platform to do the validation until we are sure that we can pass the validation. At that point we can start working on setting up an actual implementation for a lab to scrutinize.
In my opinion we should be considering this pre-validation research, which means we can loosen the actual requirements as long as we believe that we can meet those requirements when the time comes to move to the next phase.
Does that make sense or am I missing something?
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Kyle Hamilton Sent: Tuesday, October 17, 2006 8:08 PM To: Cryptography Team Development List Subject: Re: [Cryptography Team] Common Criteria Documentation...
I've updated it with my comments.
Since the system is written in itself (and runs inside itself), there are several things in the PP that require redesigning very large parts of the system. We need at least one VM hacker on this list to evaluate the feasability of some of the needed changes.
Note: The current wiki system is probably not going to be sufficient for long-term usage. Part of the EAL that we need to meet includes positive authorized user identification for all changes to the configuration... and since documentation (and an audit trail and history) will be a major part of proving our case to the assurance labs, I'm thinking that we should treat it as part of the configuration. We'll need individual usernames and passwords for the modifications until we get X.509/PKI up and running, then we'll possibly be able to use PK crypto certificates for authentication.
I'll leave it up to Krishna to determine the actual policy and implementation, since he's got formal validation experience. I just know what I've read in the CC PDFs and the single-layer OS/moderate environment document, and I'm interpreting it in the most secure (and most trust-pessimistic) manner that I can.
Here's hoping that we get at least one validation out of this in the end. :)
-Kyle H
On 10/17/06, Krishna Sankar ksankar@doubleclix.net wrote:
Have started to put the task list and notes in our cryptography Wiki
page at
http://minnow.cc.gatech.edu/squeak/5776.
For now, the cc information is at the end of the cryptography page. As
we
add more details and get a fix on the organization, we can start a set
of
new pages.
Kyle, can you pl add your notes and observations ? Thanks.
Cheers
<k/>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Krishna Sankar Sent: Tuesday, October 17, 2006 9:46 AM To: Ron@USMedRec.com; 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Common Criteria Documentation...
http://code.google.com/p/squeak-cc-validation/ = Validation documentation, plan and test results, bug tracking. This
should not
hold code.
<KS>
I would prefer to hold the validation documentation,plan and test results in a Wiki. That way we have built-in revision control as well as history tracking. In that sense the Google projects do not help us.
The bug tracking in Google projects is fine.</KS>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On
Behalf Of
Ron Teitelbaum Sent: Tuesday, October 17, 2006 9:34 AM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Common Criteria Documentation...
I thought the idea was to us SVN for those documents? If more is needed let's just use the wiki that is part of www.squeaksource.com/Cryptography
It's not a full wiki in that it doesn't appear to support
file uploads
but that what I thought the google source was for.
Can we map out what our requirements are and what our current resources are for meeting those requirements, then we can
look at what
more we need.
What I see is:
www.squeaksoruce.com/Cryptography = Code Repository and limited wiki
http://code.google.com/p/squeak-cc-validation/ = Validation documentation, plan and test results, bug tracking. This
should not
hold code.
cryptography@lists.squeakfoundation.org is our mailing list.
Ron
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On
Behalf Of
Krishna Sankar Sent: Tuesday, October 17, 2006 11:11 AM To: 'Cryptography Team Development List' Subject: RE: [Cryptography Team] Common Criteria Documentation...
Kyle,
Can you see if you have the SVN write access ? All, Just as FYI, we need gmail address to become part of the Google project and it has no Wiki. Any thoughts on the Wiki for us to document the functionalities and the results of
development/testing ?
Cheers
<k/>
> -----Original Message----- > From: cryptography-bounces@lists.squeakfoundation.org > [mailto:cryptography-bounces@lists.squeakfoundation.org]
On Behalf
> Of Kyle Hamilton > Sent: Monday, October 16, 2006 8:33 PM > To: Cryptography Team Development List > Subject: [Cryptography Team] Common Criteria Documentation... > > I found the Google Code project that Krishna started, and
uploaded
> the Common Criteria documentation I found (in PDF > form) to it as an issue. > Unfortunately, I don't have SVN write access, and I
don't know how
> to get it either. > > After reading it, I realized that it /IS/ a good idea
for anyone
> starting on CC validation to read it before they start. It's > important to realize what it is, and what the goals
must be. (As
> well, it also helps customers -- that'd include you, Ron -- > understand what the various validation levels are, and
compare them
> to regulatory > requirement.) > > -- > > -Kyle H > I speak only for myself. I don't have the faintest clue about > anyone else. > _______________________________________________ > Cryptography mailing list > Cryptography@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry > ptography >
Cryptography mailing list Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
y
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
ptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
ptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
--
-Kyle H _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Hi Kyle,
From: Kyle Hamilton Sent: Tuesday, October 17, 2006 11:26 PM
Ron,
'large number of tasks' is an understatement. :) The question is this: which validation are you looking for, first? Two (well, three, really, but only two classes of) validations have been mentioned, and my question relates to which of them resources will be allocated to -- which, in turn, defines what should go on the task list and with what priority.
FIPS 140-2 is the Trusted Cryptographic Module, which in and of itself is a huge undertaking -- a high-level overview of the things required for it are "make sure that the binary representation of the code cannot be altered", "make sure that calls into the binary representation of the code cannot be diverted", "make sure that, once in FIPS mode, only FIPS-approved algorithms can be used", "ensure that the random number generator has a good enough source of entropy AND is then stirred by a FIPS-approved pseudo-random function", and various and sundry other things. This is the validation that OpenSSL received, this is the validation that Windows CryptoAPI received, this is the validation that those two specific binary versions of Crypto++ received, this is the mandatory validation for cryptographic software that is to be used by the US government. (VM changes will be required for a validatable pure-Squeak FIPS implementation.)
Yes this is what I had in mind. My understanding though was that following common criteria was a good first step since receiving official FIPS 140-2 validation was a very large task. If CC is not possible without meeting the specifications of FIPS 140-2 (even without having an official validation) then we should start there. The things that you just mention have been the pieces that I've been considering. If they are the only pieces that are still outstanding then we should take them as tasks, assume that we will find a way around them and move onto the other validation tasks. Since they will be a long process and there is no guarantee that what we come up with will be adequate without having an official lab help to set the development agenda for qualifying our software.
As for the specific tasks you mention:
Code isolation and exclusive use of validated code, I agree with you that the right way to accomplish this is by embedding the code into the VM, and signing that VM, or having some sort of crc code checking and a signed VM. We should try to come up with what we think are options and maybe find someone connected to a lab that might be willing to consult to this group. I will take finding that person on as a task. What has me confused is that I see that Java and Eclipse have gained CC validation without FIPS 140-2 validation so it appears to me that CC is less strict, and it must be possible to gain CC validation since Java and Eclipse are both VM type environments. It might be a good idea for me to find someone from one of those teams also. I will reach out to the Eclipse community to see if I can get some help understanding the differences.
PRNG I plan to work on Bruce's FORTUNA implementation for squeak.
Common Criteria assurance validation is mandatory for entire systems that are to be used by the US government, and for information processing systems used by financial institutions. It also provides (to my understanding) assurance that is good enough for HIPAA's requirements. One of its requirements is that it use FIPS-validated cryptographic software, but it doesn't stop there -- this validation applies to entire systems and not merely the cryptographic component. In any case, the project eventually will need a FIPS-validated cryptographic component in its architecture
Ahhh this may be the point that I am missing, are you saying validation of the individual components need to meet FIPS criteria?
, be it through using a
platform-native library, a smart-card interface, or a pure-Squeak component. (VM changes will also be needed for this validation.)
You can loosen the requirements now, as long as an eye is kept on the long view. If the system is mis-architected, it will require substantial rebuilding of the VM to bring it into validatable conformance with either the Common Criteria or FIPS.
Agreed
This is the
reason why I felt that we should bring in a VM hacker now -- as it stands there is no way that, even plugging in an external FIPS library, the system could meet anything but the most basic assurance.
I've started discussing this with Klaus who agreed to help if he could, but I had to drop the ball because of some other critical commitments. But I hope to reengage that effort soon. I am very happy that Craig has also volunteered to help. My biggest concern right now is building something that we think is acceptable just to find that it misses the mark. I do like the idea of brainstorming solutions, so that we have things we can present. But I would not want to build any of them without some gut check validation with people that know.
This is going to be a long-term, many-component project, and I don't envy Krishna the management of it nor you the executive role. The least that I and anyone else can do is help you manage it. This includes making sure that every team knows at the outset what the eventual parameters will be, so no one codes themselves into a corner.
I thank you very much for your participation. I know that you will be an extremely valuable part of the team. My only concern is that we need to take this one step at a time in order to make sure that everyone is on the same page. Nothing should be assumed, and no steps should be skipped. I think that it is very important to flush out the big picture, but I want to as quickly as possible focus on manageable detail tasks. As we move forward we need feedback as to the big picture but I don't want the big picture to get in the way of actual progress. That is why I felt that the Validation Officer position was needed and why it is so important. Someone needs to manage the big picture.
A problem exists with loosening the documentation requirements for too long -- which is that if it is left for too long, the criteria simply cannot be met. Krishna suggested a Protection Profile as a target ("Single-Level Operating Systems in Medium Robustness Environments PP") which requires that the system must meet EAL 4 with some augmentations. In order to do that, there are some requirements, including partially-automated configuration management (I'm thinking that Monticello may be good enough for this, though I have not looked at it or the CC in sufficient detail to be able to state definitively), that require that only authorized changes can be made to any configuration item.
I quote paragraph 217 from the Common Criteria v2.3 Part 3 document:
217 EAL4 also provides assurance through the use of development environment controls and additional TOE configuration management including automation, and evidence of secure delivery procedures.
All of the relevant information is contained in the CC v2.3 documentation (the administrative requirements are contained in part 3). Suffice it to say, though, that one of the requirements is that no developer should be able to insert unauthorized or malicious code or information undetected -- and since the profile includes that Administrator and User documentation will be created and delivered, those documents must be kept under Configuration Management as well.
I agree with these points and agree that they are very important once we freeze development and identify a platform that will be used for validation. Since we are no where near ready for this freezing, controlling the environment is not needed. This was how OpenSSL validation worked. Once they started they picked a version and set it up for the lab. Once that was done any changes needed to be very closely tracked. I've done FDA documentation and I know the mantra, "A CHANGE IS A CHANGE IS A CHANGE". Even code COMMENTS needed to be documented in the journals for the inspectors. So once we decide that we can pass CC we will have to set this up and strictly follow all of the guidelines under the supervision of the lab.
If a wiki is used to write and edit those documents, that wiki must be able to ensure that only authorized people can modify them. It must also be able to backtrack the various changes to find when any given piece was added, removed, or altered, and who did the alteration of the documentation at that time.
Again once the document is presented in its final form.
I apologize for the length of this, but I do want to ensure that everyone is on the same page and understands the rationale behind some of my statements.
No need to apologize, I very much appreciate your contribution and encourage you to participate as much as possible. Having you on the team will help a great deal towards our goal of validation! Thank you!
You and/or Krishna are going to make decisions as
to the exact procedures that the team and project are going to use -- however, I'm an agoraphobic bachelor, and I thus have more time to research the requirements much more in-depth than you two can. This suggests that I should do so, and make recommendations based on what I have found.
Your contributions and research are very much appreciated. Sorry about your phobias. Are you working towards facing those fears?
I liken this to the role of a research librarian -- sift through mountains of data, to provide a concise report. As I said, I defer to you and Krishna -- but if you want to know the rationale behind something I suggest, I will quote you book, chapter and paragraph of everything relevant that I have found so that you can make up your own minds without having to sift through the mountains yourselves.
That will be very helpful for us to understand!
So, to sum it all up: One of the tasks that needs to be completed is to set up an authenticated configuration management system before the user and administrator documentation is written. As I said, the current wiki system will not be sufficient for the long term, but there's a huge mountain of other tasks as well. Since no administrator or user documentation is being created at this point, the wiki does not need to move to a positive identification system yet. Not in the short term, and probably not in the medium term. This doesn't mean that the eventual need shouldn't be planned for.
I agree.
(Arguably, design documents and implementation plans should also be entered into CM. Again, though, this is a long-term project, and rough ideas probably don't.)
-Kyle H
Thanks Kyle,
Ron Teitelbaum
Hey, Ron!
On 10/18/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Yes this is what I had in mind. My understanding though was that following common criteria was a good first step since receiving official FIPS 140-2 validation was a very large task. If CC is not possible without meeting the specifications of FIPS 140-2 (even without having an official validation) then we should start there.
I'm reading this to mean that all effort should be put into the cryptographic components for inclusion into the VM, with an eye toward making sure that those components won't later interfere with a CC validation... with the main responsibility for the "design won't interfere later" on Krishna. Do I understand correctly?
The things that you just mention have been the pieces that I've been considering. If they are the only pieces that are still outstanding then we should take them as tasks, assume that we will find a way around them and move onto the other validation tasks. Since they will be a long process and there is no guarantee that what we come up with will be adequate without having an official lab help to set the development agenda for qualifying our software.
Aye. I'd suggest contacting the lab that the OpenSSL team used, since they're much more likely to be amenable to concepts other than just "binary-only".
As for the specific tasks you mention: Code isolation and exclusive use of validated code, I agree with you that the right way to accomplish this is by embedding the code into the VM, and signing that VM, or having some sort of crc code checking and a signed VM.
*cough*HMAC*cough* :)
What has me confused is that I see that Java and Eclipse have gained CC validation without FIPS 140-2 validation so it appears to me that CC is less strict, and it must be possible to gain CC validation since Java and Eclipse are both VM type environments. It might be a good idea for me to find someone from one of those teams also. I will reach out to the Eclipse community to see if I can get some help understanding the differences.
Common Criteria validation does not necessarily include FIPS validation. A CC validation cannot be used to show proof of FIPS validation.
CC relates to the overall security of the system. FIPS relates solely to the cryptographic module.
Squeak could meet the CC EAL4+ requirement for FIPS validated cryptography by embedding OpenSSL, or by interfacing directly to the CryptoAPI, and not implementing any cryptography internally. (This would also allow Squeak to be used by the US government now, in low-assurance environments that require only EAL1+.)
What is the CC EAL level to which Java and Eclipse have been verified? What protection profiles have they been verified to meet?
EAL4+ is a prerequisite to the "Single-level OS/moderate assurance environments" protection profile, but that means that EAL4+ can be acheived without meeting the requirements for the protection profile. FIPS cryptography is mandatory for the protection profile, though I have not read whether it's mandatory for EAL4. ("EAL4+" means "assured to Common Criteria level 4, with some additional security-related augmentations.")
Basically, I would suggest that you read through part 1 of the Common Criteria v2.3 documentation (available in the Google svn repository) in order to understand what it is. There is also a shorter, more executive introduction to precisely what it is and is not in one of the NOSPEC documents.
PRNG I plan to work on Bruce's FORTUNA implementation for squeak.
Alright. Please read the FIPS requirement for PRNG for test vectors and such.
(I realize that this isn't really a Squeak question, but I am curious why on startup Croquet says, on Windows 2000, that there is no good source of entropy for the random number generator. This is something that should be looked at, if only to make sure that it's not poisoning this effort.)
Common Criteria assurance validation is mandatory for entire systems that are to be used by the US government, and for information processing systems used by financial institutions. It also provides (to my understanding) assurance that is good enough for HIPAA's requirements. One of its requirements is that it use FIPS-validated cryptographic software, but it doesn't stop there -- this validation applies to entire systems and not merely the cryptographic component. In any case, the project eventually will need a FIPS-validated cryptographic component in its architecture
Ahhh this may be the point that I am missing, are you saying validation of the individual components need to meet FIPS criteria?
The only component that can be FIPS-validated is the cryptographic component. (The cryptographic component, as a whole, must be validated to FIPS 140-1 or FIPS 140-2, and all cryptographic operations must be performed by that component. This means that Squeak could acquire a FIPS 140-1 validated cryptographic module and use that for the FIPS validation requirement. This doesn't change the fact that the only FIPS validation that any crypto component newly written in Squeak could acquire is 140-2.) The rest of the CC protection profile specifies how the cryptographic module is used.
(The reason for the FIPS requirement in the protection profile is political, not necessarily technical. The PP was authored by the NSA, which is mandated to use FIPS 140-x cryptography for non-classified purposes. Since the NSA creates things for its own use first, and only THEN for other people to use, it had to specify FIPS 140-x for the cryptographic components.)
My biggest concern right now is building something that we think is acceptable just to find that it misses the mark. I do like the idea of brainstorming solutions, so that we have things we can present. But I would not want to build any of them without some gut check validation with people that know.
Agreed. All we can do is read the requirements, interpret them to the best of our (fairly limited) ability, build code that conforms to the functional testing requirements, and (with guidance) figure out how to package that into a coherent, validatable whole.
At least, I'm presuming that those two (development of functional code & determinance of packaging requirements) can be parallelized.
I thank you very much for your participation. I know that you will be an extremely valuable part of the team. My only concern is that we need to take this one step at a time in order to make sure that everyone is on the same page. Nothing should be assumed, and no steps should be skipped. I think that it is very important to flush out the big picture, but I want to as quickly as possible focus on manageable detail tasks. As we move forward we need feedback as to the big picture but I don't want the big picture to get in the way of actual progress. That is why I felt that the Validation Officer position was needed and why it is so important. Someone needs to manage the big picture.
In order to get to manageable task details, I think it's important that everyone know the eventual target so that it guides them during the design and implementation. That's why I've been rushing through making sure that the eventual requirements are out on the table, so that people can look at them and understand why the tasks are happening, and what the deliverables from those tasks need to be able to support. (Bluh. I'm sounding like a middle manager. :P)
I agree with these points and agree that they are very important once we freeze development and identify a platform that will be used for validation. Since we are no where near ready for this freezing, controlling the environment is not needed. This was how OpenSSL validation worked. Once they started they picked a version and set it up for the lab. Once that was done any changes needed to be very closely tracked. I've done FDA documentation and I know the mantra, "A CHANGE IS A CHANGE IS A CHANGE". Even code COMMENTS needed to be documented in the journals for the inspectors. So once we decide that we can pass CC we will have to set this up and strictly follow all of the guidelines under the supervision of the lab.
I suppose I'm still thinking in terms of TCSEC -- everything had to be documented from the outset. Ah well -- welcome to the new world. ;)
No need to apologize, I very much appreciate your contribution and encourage you to participate as much as possible. Having you on the team will help a great deal towards our goal of validation! Thank you!
It's something I'm good at, and I enjoy. Thank you for having me!
You and/or Krishna are going to make decisions as to the exact procedures that the team and project are going to use -- however, I'm an agoraphobic bachelor, and I thus have more time to research the requirements much more in-depth than you two can. This suggests that I should do so, and make recommendations based on what I have found.
Your contributions and research are very much appreciated. Sorry about your phobias. Are you working towards facing those fears?
I am, yes, but I don't particularly want to make that a discussion point. I brought it up as an explanation for what I'm doing (researching), why I'm doing it (to help you make informed decisions), and the situation that makes it possible (so that you understand that I actually am reading these things, putting my intellect toward understanding them, and not just making stuff up).
I liken this to the role of a research librarian -- sift through mountains of data, to provide a concise report. As I said, I defer to you and Krishna -- but if you want to know the rationale behind something I suggest, I will quote you book, chapter and paragraph of everything relevant that I have found so that you can make up your own minds without having to sift through the mountains yourselves.
That will be very helpful for us to understand!
Also, you can ask me to find out about some aspect, and I'll come up with a report of my understanding of the issue after research, as well as the precise sources I found related to it. (The CC documents make it easy by numbering their paragraphs. :) )
I should point out: I'm very interested in cryptography, but am not at all good at coding Smalltalk yet. I'm still wrapping my head around "everything AND I DO MEAN EVERYTHING is an object".
Wish I'd grown up with Smalltalk instead of Applesoft BASIC. ;)
Cheers!
-Kyle H
Kyle,
I was going to reply to the good e-mail exchanges, but Ron has articulated well what ever good things I had to say ! Anyway, am going to harvest a task list out of your detailed e-mails. Pl keep on digging into the docs and add notes to the Wiki. Let us first internalize the various aspects of this beast and at some point (most probably in a month or so) distill a set of tasks to begin.
Cheers <k/>
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Kyle Hamilton Sent: Wednesday, October 18, 2006 1:49 PM To: Ron@usmedrec.com; Cryptography Team Development List Subject: Re: [Cryptography Team] Common Criteria Documentation...
Hey, Ron!
On 10/18/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Yes this is what I had in mind. My understanding though was that following common criteria was a good first step since receiving official FIPS 140-2 validation was a very large task. If CC is not possible without meeting the specifications of FIPS 140-2 (even without having an official validation) then we should start there.
I'm reading this to mean that all effort should be put into the cryptographic components for inclusion into the VM, with an eye toward making sure that those components won't later interfere with a CC validation... with the main responsibility for the "design won't interfere later" on Krishna. Do I understand correctly?
The things that you just mention have been the pieces that
I've been
considering. If they are the only pieces that are still
outstanding
then we should take them as tasks, assume that we will find a way around them and move onto the other validation tasks.
Since they will
be a long process and there is no guarantee that what we
come up with
will be adequate without having an official lab help to set the development agenda for qualifying our software.
Aye. I'd suggest contacting the lab that the OpenSSL team used, since they're much more likely to be amenable to concepts other than just "binary-only".
As for the specific tasks you mention: Code isolation and exclusive use of validated code, I agree
with you
that the right way to accomplish this is by embedding the code into the VM, and signing that VM, or having some sort of crc
code checking and a signed VM.
*cough*HMAC*cough* :)
What has me confused is that I see that Java and Eclipse have gained CC validation without FIPS 140-2 validation so it appears to me that CC is less strict, and it must be possible to gain CC validation since Java and
Eclipse are both
VM type environments. It might be a good idea for me to
find someone
from one of those teams also. I will reach out to the Eclipse community to see if I can get some help understanding the
differences.
Common Criteria validation does not necessarily include FIPS validation. A CC validation cannot be used to show proof of FIPS validation.
CC relates to the overall security of the system. FIPS relates solely to the cryptographic module.
Squeak could meet the CC EAL4+ requirement for FIPS validated cryptography by embedding OpenSSL, or by interfacing directly to the CryptoAPI, and not implementing any cryptography internally. (This would also allow Squeak to be used by the US government now, in low-assurance environments that require only EAL1+.)
What is the CC EAL level to which Java and Eclipse have been verified? What protection profiles have they been verified to meet?
EAL4+ is a prerequisite to the "Single-level OS/moderate assurance environments" protection profile, but that means that EAL4+ can be acheived without meeting the requirements for the protection profile. FIPS cryptography is mandatory for the protection profile, though I have not read whether it's mandatory for EAL4. ("EAL4+" means "assured to Common Criteria level 4, with some additional security-related augmentations.")
Basically, I would suggest that you read through part 1 of the Common Criteria v2.3 documentation (available in the Google svn repository) in order to understand what it is. There is also a shorter, more executive introduction to precisely what it is and is not in one of the NOSPEC documents.
PRNG I plan to work on Bruce's FORTUNA implementation for squeak.
Alright. Please read the FIPS requirement for PRNG for test vectors and such.
(I realize that this isn't really a Squeak question, but I am curious why on startup Croquet says, on Windows 2000, that there is no good source of entropy for the random number generator. This is something that should be looked at, if only to make sure that it's not poisoning this effort.)
Common Criteria assurance validation is mandatory for
entire systems
that are to be used by the US government, and for information processing systems used by financial institutions. It
also provides
(to my understanding) assurance that is good enough for HIPAA's requirements. One of its requirements is that it use
FIPS-validated
cryptographic software, but it doesn't stop there -- this
validation
applies to entire systems and not merely the
cryptographic component.
In any case, the project eventually will need a FIPS-validated cryptographic component in its architecture
Ahhh this may be the point that I am missing, are you saying validation of the individual components need to meet FIPS criteria?
The only component that can be FIPS-validated is the cryptographic component. (The cryptographic component, as a whole, must be validated to FIPS 140-1 or FIPS 140-2, and all cryptographic operations must be performed by that component. This means that Squeak could acquire a FIPS 140-1 validated cryptographic module and use that for the FIPS validation requirement. This doesn't change the fact that the only FIPS validation that any crypto component newly written in Squeak could acquire is 140-2.) The rest of the CC protection profile specifies how the cryptographic module is used.
(The reason for the FIPS requirement in the protection profile is political, not necessarily technical. The PP was authored by the NSA, which is mandated to use FIPS 140-x cryptography for non-classified purposes. Since the NSA creates things for its own use first, and only THEN for other people to use, it had to specify FIPS 140-x for the cryptographic components.)
My biggest concern right now is building something that we think is acceptable just to find that it misses the mark. I do like
the idea
of brainstorming solutions, so that we have things we can present. But I would not want to build any of them without some gut check validation with people that know.
Agreed. All we can do is read the requirements, interpret them to the best of our (fairly limited) ability, build code that conforms to the functional testing requirements, and (with guidance) figure out how to package that into a coherent, validatable whole.
At least, I'm presuming that those two (development of functional code & determinance of packaging requirements) can be parallelized.
I thank you very much for your participation. I know that
you will be
an extremely valuable part of the team. My only concern is that we need to take this one step at a time in order to make sure that everyone is on the same page. Nothing should be assumed,
and no steps
should be skipped. I think that it is very important to
flush out the
big picture, but I want to as quickly as possible focus on
manageable
detail tasks. As we move forward we need feedback as to the big picture but I don't want the big picture to get in the way
of actual
progress. That is why I felt that the Validation Officer
position was
needed and why it is so important. Someone needs to manage
the big picture.
In order to get to manageable task details, I think it's important that everyone know the eventual target so that it guides them during the design and implementation. That's why I've been rushing through making sure that the eventual requirements are out on the table, so that people can look at them and understand why the tasks are happening, and what the deliverables from those tasks need to be able to support. (Bluh. I'm sounding like a middle manager. :P)
I agree with these points and agree that they are very
important once
we freeze development and identify a platform that will be
used for validation.
Since we are no where near ready for this freezing, controlling the environment is not needed. This was how OpenSSL validation
worked.
Once they started they picked a version and set it up for the lab. Once that was done any changes needed to be very closely tracked. I've done FDA documentation and I know the mantra, "A
CHANGE IS A CHANGE IS A CHANGE".
Even code COMMENTS needed to be documented in the journals for the inspectors. So once we decide that we can pass CC we will
have to set
this up and strictly follow all of the guidelines under the supervision of the lab.
I suppose I'm still thinking in terms of TCSEC -- everything had to be documented from the outset. Ah well -- welcome to the new world. ;)
No need to apologize, I very much appreciate your contribution and encourage you to participate as much as possible. Having
you on the
team will help a great deal towards our goal of validation!
Thank you!
It's something I'm good at, and I enjoy. Thank you for having me!
You and/or Krishna are going to make decisions as to the exact procedures that the team and project are going to use -- however, I'm an agoraphobic bachelor, and I thus have more time to
research
the requirements much more in-depth than you two can.
This suggests
that I should do so, and make recommendations based on
what I have
found.
Your contributions and research are very much appreciated. Sorry about your phobias. Are you working towards facing those fears?
I am, yes, but I don't particularly want to make that a discussion point. I brought it up as an explanation for what I'm doing (researching), why I'm doing it (to help you make informed decisions), and the situation that makes it possible (so that you understand that I actually am reading these things, putting my intellect toward understanding them, and not just making stuff up).
I liken this to the role of a research librarian -- sift through mountains of data, to provide a concise report. As I
said, I defer
to you and Krishna -- but if you want to know the
rationale behind
something I suggest, I will quote you book, chapter and
paragraph of
everything relevant that I have found so that you can
make up your
own minds without having to sift through the mountains yourselves.
That will be very helpful for us to understand!
Also, you can ask me to find out about some aspect, and I'll come up with a report of my understanding of the issue after research, as well as the precise sources I found related to it. (The CC documents make it easy by numbering their paragraphs. :) )
I should point out: I'm very interested in cryptography, but am not at all good at coding Smalltalk yet. I'm still wrapping my head around "everything AND I DO MEAN EVERYTHING is an object".
Wish I'd grown up with Smalltalk instead of Applesoft BASIC. ;)
Cheers!
-Kyle H _______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry ptography
Hey Kyle,
From: Kyle Hamilton Sent: Wednesday, October 18, 2006 4:49 PM
Hey, Ron!
On 10/18/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Yes this is what I had in mind. My understanding though was that
following
common criteria was a good first step since receiving official FIPS 140-
2
validation was a very large task. If CC is not possible without meeting
the
specifications of FIPS 140-2 (even without having an official
validation)
then we should start there.
I'm reading this to mean that all effort should be put into the cryptographic components for inclusion into the VM, with an eye toward making sure that those components won't later interfere with a CC validation... with the main responsibility for the "design won't interfere later" on Krishna. Do I understand correctly?
I'm not sure I would put it that way. Let me reword my intention in my own words and see if they match what you are saying. My goal is to first set up an organized plan of attack. I specifically asked Krishna to keep an eye on the larger goal but to provide us with a road map that consists of a short list of items that need to be accomplished. We will work on a high level feedback mechanism so that we can all see the big picture and where we are in that larger process, but I want to make sure that the current tasks are highlighted, considered carefully, and that the list of To-do's is short and manageable.
The design of code and handling of each task will be the responsibility of the group with an eye on following the standards as closely as possible so that we can achieve CC validation.
My job is simply to provide what ever support the group needs, to reach out and find resources, to remove any roadblocks we encounter, and to code along with the other volunteers.
The things that you just mention have been the pieces that I've been considering. If they are the only pieces that are still outstanding then we should take them as tasks, assume that we will find a way around them and move onto the other validation tasks. Since
they
will be a long process and there is no guarantee that what we come up
with
will be adequate without having an official lab help to set the
development
agenda for qualifying our software.
Aye. I'd suggest contacting the lab that the OpenSSL team used, since they're much more likely to be amenable to concepts other than just "binary-only".
As for the specific tasks you mention: Code isolation and exclusive use of validated code, I agree with you
that
the right way to accomplish this is by embedding the code into the VM,
and
signing that VM, or having some sort of crc code checking and a signed
VM.
*cough*HMAC*cough* :)
What has me confused is that I see that Java and Eclipse have gained CC validation without FIPS 140-2 validation so it appears to me that CC is less strict, and it must be possible to gain CC validation since Java and Eclipse are both VM type environments. It might be a good idea for me to find someone from one
of
those teams also. I will reach out to the Eclipse community to see if I
can
get some help understanding the differences.
Common Criteria validation does not necessarily include FIPS validation. A CC validation cannot be used to show proof of FIPS validation.
CC relates to the overall security of the system. FIPS relates solely to the cryptographic module.
Squeak could meet the CC EAL4+ requirement for FIPS validated cryptography by embedding OpenSSL, or by interfacing directly to the CryptoAPI, and not implementing any cryptography internally. (This would also allow Squeak to be used by the US government now, in low-assurance environments that require only EAL1+.)
Yes and I would agree that this is a subject that we will need to discuss as a group.
What is the CC EAL level to which Java and Eclipse have been verified? What protection profiles have they been verified to meet?
EAL4: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.i bm.websphere.express.doc/info/exp/ae/rovr_commoncriteria.html
EAL4+ is a prerequisite to the "Single-level OS/moderate assurance environments" protection profile, but that means that EAL4+ can be acheived without meeting the requirements for the protection profile. FIPS cryptography is mandatory for the protection profile, though I have not read whether it's mandatory for EAL4. ("EAL4+" means "assured to Common Criteria level 4, with some additional security-related augmentations.")
Basically, I would suggest that you read through part 1 of the Common Criteria v2.3 documentation (available in the Google svn repository) in order to understand what it is. There is also a shorter, more executive introduction to precisely what it is and is not in one of the NOSPEC documents.
PRNG I plan to work on Bruce's FORTUNA implementation for squeak.
Alright. Please read the FIPS requirement for PRNG for test vectors and such.
(I realize that this isn't really a Squeak question, but I am curious why on startup Croquet says, on Windows 2000, that there is no good source of entropy for the random number generator. This is something that should be looked at, if only to make sure that it's not poisoning this effort.)
Andreas mentioned this to me; he is using a primitive call to an OS level PRNG as entropy. For Fortuna we need many more sources of entropy then that. I will read through the requirements before starting this project.
Common Criteria assurance validation is mandatory for entire systems that are to be used by the US government, and for information processing systems used by financial institutions. It also provides (to my understanding) assurance that is good enough for HIPAA's requirements. One of its requirements is that it use FIPS-validated cryptographic software, but it doesn't stop there -- this validation applies to entire systems and not merely the cryptographic component. In any case, the project eventually will need a FIPS-validated cryptographic component in its architecture
Ahhh this may be the point that I am missing, are you saying validation
of
the individual components need to meet FIPS criteria?
The only component that can be FIPS-validated is the cryptographic component. (The cryptographic component, as a whole, must be validated to FIPS 140-1 or FIPS 140-2, and all cryptographic operations must be performed by that component. This means that Squeak could acquire a FIPS 140-1 validated cryptographic module and use that for the FIPS validation requirement. This doesn't change the fact that the only FIPS validation that any crypto component newly written in Squeak could acquire is 140-2.) The rest of the CC protection profile specifies how the cryptographic module is used.
I was asked by the lab I spoke with if we planned on doing individual component validation or system validation. There feeling was that individual component validation is included in system validation so that having each component validated separately was not necessary.
(The reason for the FIPS requirement in the protection profile is political, not necessarily technical. The PP was authored by the NSA, which is mandated to use FIPS 140-x cryptography for non-classified purposes. Since the NSA creates things for its own use first, and only THEN for other people to use, it had to specify FIPS 140-x for the cryptographic components.)
My biggest concern right now is building something that we think is acceptable just to find that it misses the mark. I do
like
the idea of brainstorming solutions, so that we have things we can
present.
But I would not want to build any of them without some gut check
validation
with people that know.
Agreed. All we can do is read the requirements, interpret them to the best of our (fairly limited) ability, build code that conforms to the functional testing requirements, and (with guidance) figure out how to package that into a coherent, validatable whole.
At least, I'm presuming that those two (development of functional code & determinance of packaging requirements) can be parallelized.
My feeling is that we will need to do most of this by ourselves. I will try to find more consultants for high level review. I do not expect to bring in a lab until we are satisfied that we are very close, except for maybe an initial consultation, or as needed to answer questions if we feel we are off track.
I thank you very much for your participation. I know that you will be
an
extremely valuable part of the team. My only concern is that we need to take this one step at a time in order to make sure that everyone is on
the
same page. Nothing should be assumed, and no steps should be skipped.
I
think that it is very important to flush out the big picture, but I want
to
as quickly as possible focus on manageable detail tasks. As we move
forward
we need feedback as to the big picture but I don't want the big picture
to
get in the way of actual progress. That is why I felt that the
Validation
Officer position was needed and why it is so important. Someone needs
to
manage the big picture.
In order to get to manageable task details, I think it's important that everyone know the eventual target so that it guides them during the design and implementation. That's why I've been rushing through making sure that the eventual requirements are out on the table, so that people can look at them and understand why the tasks are happening, and what the deliverables from those tasks need to be able to support. (Bluh. I'm sounding like a middle manager. :P)
I agree with these points and agree that they are very important once we freeze development and identify a platform that will be used for
validation.
Since we are no where near ready for this freezing, controlling the environment is not needed. This was how OpenSSL validation worked.
Once
they started they picked a version and set it up for the lab. Once that
was
done any changes needed to be very closely tracked. I've done FDA documentation and I know the mantra, "A CHANGE IS A CHANGE IS A CHANGE". Even code COMMENTS needed to be documented in the journals for the inspectors. So once we decide that we can pass CC we will have to set
this
up and strictly follow all of the guidelines under the supervision of
the
lab.
I suppose I'm still thinking in terms of TCSEC -- everything had to be documented from the outset. Ah well -- welcome to the new world. ;)
No need to apologize, I very much appreciate your contribution and
encourage
you to participate as much as possible. Having you on the team will
help a
great deal towards our goal of validation! Thank you!
It's something I'm good at, and I enjoy. Thank you for having me!
You and/or Krishna are going to make decisions as to the exact procedures that the team and project are going to use -- however, I'm an agoraphobic bachelor, and I thus have more time to research the requirements much more in-depth than you two can. This suggests that I should do so, and make recommendations based on what I have found.
Your contributions and research are very much appreciated. Sorry about
your
phobias. Are you working towards facing those fears?
I am, yes, but I don't particularly want to make that a discussion point. I brought it up as an explanation for what I'm doing (researching), why I'm doing it (to help you make informed decisions), and the situation that makes it possible (so that you understand that I actually am reading these things, putting my intellect toward understanding them, and not just making stuff up).
I liken this to the role of a research librarian -- sift through mountains of data, to provide a concise report. As I said, I defer to you and Krishna -- but if you want to know the rationale behind something I suggest, I will quote you book, chapter and paragraph of everything relevant that I have found so that you can make up your own minds without having to sift through the mountains yourselves.
That will be very helpful for us to understand!
Also, you can ask me to find out about some aspect, and I'll come up with a report of my understanding of the issue after research, as well as the precise sources I found related to it. (The CC documents make it easy by numbering their paragraphs. :) )
Will do!
I should point out: I'm very interested in cryptography, but am not at all good at coding Smalltalk yet. I'm still wrapping my head around "everything AND I DO MEAN EVERYTHING is an object".
Wish I'd grown up with Smalltalk instead of Applesoft BASIC. ;)
Cheers!
-Kyle H
Ron Teitelbaum
On 10/18/06, Ron Teitelbaum Ron@usmedrec.com wrote:
I'm not sure I would put it that way. Let me reword my intention in my own words and see if they match what you are saying. My goal is to first set up an organized plan of attack. I specifically asked Krishna to keep an eye on the larger goal but to provide us with a road map that consists of a short list of items that need to be accomplished. We will work on a high level feedback mechanism so that we can all see the big picture and where we are in that larger process, but I want to make sure that the current tasks are highlighted, considered carefully, and that the list of To-do's is short and manageable.
Every list of To-do's is made up of a thousand details. If I read this right, you want basically the top and some of the second-level items in the outline, so that it can be distributed to each group... and each group determines what's necessary.
I can understand your desire and need to keep it manageable -- you are, essentially, the resource manager (as well as a resource!), and Krishna is the project manager. You need to have a high-level overview of what kinds of resources (people, time, money) are going to be needed, at what points in the process, so that you can make sure that they're allocated properly (and not be surprised later on).
Krishna's job, on the other hand, is the more detailed one. This is not a simple process. Each and every single detail needs to be checked and doublechecked -- yes, over time, the details can be fleshed out for each group, but at this point the resource requirements (and the support needed) aren't really known by anyone. He needs as much information as he can get so that over the next month, he can figure out the tasks, figure out what the bullet points must be -- and figure out what resources will be needed for each task.
After he figures that out and publishes it for you and all other volunteers (including himself, you, me, every member of the VM team, every member of the cryptography team, every member of the UI team, every member of the documentation team, and everyone else who isn't even on a team yet), that's when you can really do your job. Krishna will identify the questions that need to be answered, the roadblocks in the way, the direction that the project needs to go, and basically the tasks that need resources assigned to them.
My job right now, as requested by Krishna, is to feed him as much information as possible, and help him identify questions that need to be answered before he can figure out what the top-level tasks will end up being. I expect that he'll consult with you regarding the questions he has; I can provide information from the published documents, but I can't interface with any external organizations (that's a POC function, and I think someone appointed by the Squeak Foundation itself should do that -- which is you).
There appears to be some confusion remaining as to what is being required, by whom. The sense that you got from the evaluation organization you spoke with seemed to be that a systemic evaluation included component evaluation, where I'm seeing that there is a political distinction being made by the CSRC at NIST, by the NSA, and by US Code. (I will be happily surprised if this distinction that I'm seeing really isn't there, and that the FIPS validation can occur as part of the CC validation... but I would be remiss if I didn't point out the possibility that the sense you got from the conversation wasn't necessarily the sense that the person who the conversation was with was trying to convey, or that the person who conveyed had a misunderstanding himself.)
Remember: an application may use FIPS-specified cryptographic algorithms, PRNG algorithms, key seeding mechanisms, etc -- but it's not FIPS unless the cryptographic component is validated by an independent testing organization.
The design of code and handling of each task will be the responsibility of the group with an eye on following the standards as closely as possible so that we can achieve CC validation.
Again, which CC protection profile validation are we attempting to achieve? Krishna has identified one that exists, that may or may not be what we are attempting to work toward. One of the roadblocks that exists right now is that not all of us are on the same page as regards eventual destination.
Squeak could meet the CC EAL4+ requirement for FIPS validated cryptography by embedding OpenSSL, or by interfacing directly to the CryptoAPI, and not implementing any cryptography internally. (This would also allow Squeak to be used by the US government now, in low-assurance environments that require only EAL1+.)
Yes and I would agree that this is a subject that we will need to discuss as a group.
Yes, not only on the cryptography list, but also on the main Squeak-dev list. It is also probably something that the Squeak Foundation board will have to discuss and agree on.
The way I would frame the question is thus: How quickly do we want government agencies to be able to consider Squeak as part of their acquisition strategy? Is it worth doing in multiple phases -- i.e., make it possible now, and then work on progressively more detailed assurance levels until it finally meets the eventual protection profile goal? As an alternative, should we do it in two phases by adding FIPS now, and then meet the eventual Common Criteria validation destination several years down the road, with no intermediate validations? Or, should we just not worry about the government, and only present it to them with the final destination's validation?
I suspect there are other considerations that I'm not thinking about.
What is the CC EAL level to which Java and Eclipse have been verified? What protection profiles have they been verified to meet?
EAL4: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.i bm.websphere.express.doc/info/exp/ae/rovr_commoncriteria.html
From what I read there, Websphere has been verified to meet EAL4 in a
specific configuration. That does not necessarily mean that Java itself has been, nor does it necessarily mean that Eclipse has been.
The standard Websphere configuration is not EAL4 verified -- it takes downloading and faithfully following a 1 meg PDF to deploy it in a CC verified configuration.
Even then, it uses separately-FIPS-validated Java class libraries.
(I realize that this isn't really a Squeak question, but I am curious why on startup Croquet says, on Windows 2000, that there is no good source of entropy for the random number generator. This is something that should be looked at, if only to make sure that it's not poisoning this effort.)
Andreas mentioned this to me; he is using a primitive call to an OS level PRNG as entropy. For Fortuna we need many more sources of entropy then that. I will read through the requirements before starting this project.
On Windows, the HKLM\Software\Microsoft\Cryptography\Rng\Seed registry key is available, as is the CryptoAPI's RC4-based entropy generator.
I was asked by the lab I spoke with if we planned on doing individual component validation or system validation. There feeling was that individual component validation is included in system validation so that having each component validated separately was not necessary.
Again, I'm not sure if their interpretation is correct. I'll look at the various interpretations documents and see what I can find out -- but someone at the CSRC may be a better source of information.
At least, I'm presuming that those two (development of functional code & determinance of packaging requirements) can be parallelized.
My feeling is that we will need to do most of this by ourselves. I will try to find more consultants for high level review. I do not expect to bring in a lab until we are satisfied that we are very close, except for maybe an initial consultation, or as needed to answer questions if we feel we are off track.
Aye.
Thanks again,
-Kyle H
Hi Kyle,
It looks like we are getting closer, but still slightly off. Let's see if we can move more towards each other in our differences.
From: Kyle Hamilton Sent: Friday, October 20, 2006 1:02 AM
On 10/18/06, Ron Teitelbaum Ron@usmedrec.com wrote:
I'm not sure I would put it that way. Let me reword my intention in my
own
words and see if they match what you are saying. My goal is to first
set up
an organized plan of attack. I specifically asked Krishna to keep an
eye on
the larger goal but to provide us with a road map that consists of a
short
list of items that need to be accomplished. We will work on a high
level
feedback mechanism so that we can all see the big picture and where we
are
in that larger process, but I want to make sure that the current tasks
are
highlighted, considered carefully, and that the list of To-do's is short
and
manageable.
Every list of To-do's is made up of a thousand details. If I read this right, you want basically the top and some of the second-level items in the outline, so that it can be distributed to each group... and each group determines what's necessary.
Not quite since there is really only one group. We can work towards reaching out to other groups but only as we identify areas where we need help. I don't believe that we have the resources to do things in parallel.
I can understand your desire and need to keep it manageable -- you are, essentially, the resource manager (as well as a resource!), and Krishna is the project manager.
Yes.
You need to have a high-level overview of what kinds of resources (people, time, money) are going to be needed, at what points in the process, so that you can make sure that they're allocated properly (and not be surprised later on).
Yes.
Krishna's job, on the other hand, is the more detailed one. This is not a simple process. Each and every single detail needs to be checked and doublechecked -- yes, over time, the details can be fleshed out for each group, but at this point the resource requirements (and the support needed) aren't really known by anyone. He needs as much information as he can get so that over the next month, he can figure out the tasks, figure out what the bullet points must be -- and figure out what resources will be needed for each task.
Now here is where we get off track again. Kristna's job is organization research and feedback. Nobody in our group in an expert, and we will all contribute towards the process, tasks and big picture. I don't expect that Kristna will be able to know everything, although he has considerable experience interpreting government requirements, so I expect that his contribution to defining the process will be considerable.
Let me spell this out as distinctly as possible: The tasks ahead of us are huge; my goal right now is process. The goal is not even CC or FIPS Validation, it is process. Krishna's job right now is process. He is a facilitator and an organizer. We will all work together to make sure that we answer the questions that Krishna has. Keep in mind what I mean by a small list of TO-Do's. Considering the number of resources we have, a major goal is to simplify the process into manageable chunks. This simplification may result in the process being extended indefinitely but as we work through and improve the process it will be possible for us to attract more resources. Think of this first part as moving up a big hill and starting in low gear!
After he figures that out and publishes it for you and all other volunteers (including himself, you, me, every member of the VM team, every member of the cryptography team, every member of the UI team, every member of the documentation team, and everyone else who isn't even on a team yet), that's when you can really do your job. Krishna will identify the questions that need to be answered, the roadblocks in the way, the direction that the project needs to go, and basically the tasks that need resources assigned to them.
My job right now, as requested by Krishna, is to feed him as much information as possible, and help him identify questions that need to be answered before he can figure out what the top-level tasks will end up being. I expect that he'll consult with you regarding the questions he has; I can provide information from the published documents, but I can't interface with any external organizations (that's a POC function, and I think someone appointed by the Squeak Foundation itself should do that -- which is you).
My task for you would be to help define the big picture but only in very broad strokes. I think that putting together and understanding the process and where we might need to be steered back onto the road and out of a ditch is what you will be very good at. As for actual work instead of steering I would like you to help focus on the actual first task as defined by Krishna. You are right we are waiting for a process and a first task from Krishna. The first task may be something like what are the steps to accomplish the first task. Or what is the process for determining the first task. I know it sounds simple but there is a huge benefit toward organization, and that right now is our goal.
There appears to be some confusion remaining as to what is being required, by whom. The sense that you got from the evaluation organization you spoke with seemed to be that a systemic evaluation included component evaluation, where I'm seeing that there is a political distinction being made by the CSRC at NIST, by the NSA, and by US Code. (I will be happily surprised if this distinction that I'm seeing really isn't there, and that the FIPS validation can occur as part of the CC validation... but I would be remiss if I didn't point out the possibility that the sense you got from the conversation wasn't necessarily the sense that the person who the conversation was with was trying to convey, or that the person who conveyed had a misunderstanding himself.)
Remember: an application may use FIPS-specified cryptographic algorithms, PRNG algorithms, key seeding mechanisms, etc -- but it's not FIPS unless the cryptographic component is validated by an independent testing organization.
Ok understood, but my understanding is FIPS validation of cryptographic components can be done as a separate process, we could have both a system validation and a cryptographic component validations, my understanding is that there is little value to having the individual components validated if the systems as a whole is validated. I could be wrong, but it sounded to me like more money spent for little value.
The design of code and handling of each task will be the responsibility
of
the group with an eye on following the standards as closely as possible
so
that we can achieve CC validation.
Again, which CC protection profile validation are we attempting to achieve? Krishna has identified one that exists, that may or may not be what we are attempting to work toward. One of the roadblocks that exists right now is that not all of us are on the same page as regards eventual destination.
Right this is something we need to decide.
Squeak could meet the CC EAL4+ requirement for FIPS validated cryptography by embedding OpenSSL, or by interfacing directly to the CryptoAPI, and not implementing any cryptography internally. (This would also allow Squeak to be used by the US government now, in low-assurance environments that require only EAL1+.)
Yes and I would agree that this is a subject that we will need to
discuss as
a group.
Yes, not only on the cryptography list, but also on the main Squeak-dev list. It is also probably something that the Squeak Foundation board will have to discuss and agree on.
I disagree here, we can reach out for help when we need to but few people are interested in what we are doing (regrettably). We will decide what we are going to work on, it may not be a consensus decision, and it may not be valuable to everyone but it will get us somewhere that we are not today.
The way I would frame the question is thus: How quickly do we want government agencies to be able to consider Squeak as part of their acquisition strategy? Is it worth doing in multiple phases -- i.e., make it possible now, and then work on progressively more detailed assurance levels until it finally meets the eventual protection profile goal? As an alternative, should we do it in two phases by adding FIPS now, and then meet the eventual Common Criteria validation destination several years down the road, with no intermediate validations? Or, should we just not worry about the government, and only present it to them with the final destination's validation?
I suspect there are other considerations that I'm not thinking about.
These are things we will need to decide.
What is the CC EAL level to which Java and Eclipse have been verified? What protection profiles have they been verified to meet?
EAL4:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com .i
bm.websphere.express.doc/info/exp/ae/rovr_commoncriteria.html
From what I read there, Websphere has been verified to meet EAL4 in a specific configuration. That does not necessarily mean that Java itself has been, nor does it necessarily mean that Eclipse has been.
The standard Websphere configuration is not EAL4 verified -- it takes downloading and faithfully following a 1 meg PDF to deploy it in a CC verified configuration.
Right but this is our goal too! Understand that the value of our work is this document. Our goal is to provide a map to others building applications and deploying them deliver CC validated software. Our goal is not to validate Squeak or to have a validated running implementation it is to allow others to have that. We have to set up a running implementation so that a lab can poke at it, but after that it goes away and what we did to get the system validated becomes that large implementation guide. The goal is the implantation guide and deployed validated commercial Squeak software. We won't be doing the deployment but we might consult with people that want too (to help fund the group!)
Even then, it uses separately-FIPS-validated Java class libraries.
Again I don't think that individual validation is necessary, but I could be wrong. When we are ready to talk to a lab we will bring this up again, if we need individual component validation we will raise money for it at that time.
(I realize that this isn't really a Squeak question, but I am curious why on startup Croquet says, on Windows 2000, that there is no good source of entropy for the random number generator. This is something that should be looked at, if only to make sure that it's not poisoning this effort.)
Andreas mentioned this to me; he is using a primitive call to an OS
level
PRNG as entropy. For Fortuna we need many more sources of entropy then that. I will read through the requirements before starting this
project.
On Windows, the HKLM\Software\Microsoft\Cryptography\Rng\Seed registry key is available, as is the CryptoAPI's RC4-based entropy generator.
Terrific I will look at this more closely to see if it will work. We need 32 separate entropy sources for Fortuna! It will be a fun project! Maybe we could start a list on wiki?
I was asked by the lab I spoke with if we planned on doing individual component validation or system validation. There feeling was that individual component validation is included in system validation so that having each component validated separately was not necessary.
Again, I'm not sure if their interpretation is correct. I'll look at the various interpretations documents and see what I can find out -- but someone at the CSRC may be a better source of information.
OK!
At least, I'm presuming that those two (development of functional code & determinance of packaging requirements) can be parallelized.
My feeling is that we will need to do most of this by ourselves. I will
try
to find more consultants for high level review. I do not expect to
bring in
a lab until we are satisfied that we are very close, except for maybe an initial consultation, or as needed to answer questions if we feel we are
off
track.
Aye.
Thanks again,
-Kyle H
Thanks,
Ron
Hi Ron!
Okay. Now I think we're MUCH closer to understanding.
Krishna did ask me for detail, to be put onto the wiki -- not only related to CC, but also to FIPS. (A separate FIPS certification for the cryptographic component is mandatory if a sysem is to be used in the US government to handle any confidential data, per the Federal Information Security Management Act of 2002. This is where my confusion comes in related to it, but it's something that can be put on hold for a while.)
Your statement is that the immediate goal is the development of the process through which we can meet all criteria necessary for validation. This is perfectly reasonable, especially as the process requirements will be close to the same for whatever validations we go through.
Krishna asked me to put as much detail in the wiki as I can related to functional and process requirements. It is my sense that he wants to design a process to modify Squeak for validation with as little red tape as possible for the people involved, while still adhering to the requirements necessary. (At least, I hope that's his goal. I wouldn't want too much red tape, myself.)
If there are few people outside of the cryptography list who are interested in getting Squeak ready to be validated, then the target may end up taking the form of a separate Monticello package with all of the modifications to the VM classes necessary, and instructions on how to build a CC-conforming VM and systems based on it. (Yay documentation :) ) I don't know, and right now I'm tossing ideas out on the table simply because of that. I'm not the one who's going to determine the final destination, nor the path by which we get there.
So. If the goal is the process, then I'll find everything I can related to the process requirements and put it on the wiki so that you and Krishna can figure out ways that they can be met without imposing too huge an overhead on the volunteers involved. Functional requirements that I find will also go on the wiki (in a separate page), so that they can be distilled into an overall architecture... while presumably still leaving room for individual design and development.
Which seems to be the way that most successful open-source projects do it anyway. :)
-Kyle H
On 10/20/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Hi Kyle,
It looks like we are getting closer, but still slightly off. Let's see if we can move more towards each other in our differences.
From: Kyle Hamilton Sent: Friday, October 20, 2006 1:02 AM
On 10/18/06, Ron Teitelbaum Ron@usmedrec.com wrote:
I'm not sure I would put it that way. Let me reword my intention in my
own
words and see if they match what you are saying. My goal is to first
set up
an organized plan of attack. I specifically asked Krishna to keep an
eye on
the larger goal but to provide us with a road map that consists of a
short
list of items that need to be accomplished. We will work on a high
level
feedback mechanism so that we can all see the big picture and where we
are
in that larger process, but I want to make sure that the current tasks
are
highlighted, considered carefully, and that the list of To-do's is short
and
manageable.
Every list of To-do's is made up of a thousand details. If I read this right, you want basically the top and some of the second-level items in the outline, so that it can be distributed to each group... and each group determines what's necessary.
Not quite since there is really only one group. We can work towards reaching out to other groups but only as we identify areas where we need help. I don't believe that we have the resources to do things in parallel.
I can understand your desire and need to keep it manageable -- you are, essentially, the resource manager (as well as a resource!), and Krishna is the project manager.
Yes.
You need to have a high-level overview of what kinds of resources (people, time, money) are going to be needed, at what points in the process, so that you can make sure that they're allocated properly (and not be surprised later on).
Yes.
Krishna's job, on the other hand, is the more detailed one. This is not a simple process. Each and every single detail needs to be checked and doublechecked -- yes, over time, the details can be fleshed out for each group, but at this point the resource requirements (and the support needed) aren't really known by anyone. He needs as much information as he can get so that over the next month, he can figure out the tasks, figure out what the bullet points must be -- and figure out what resources will be needed for each task.
Now here is where we get off track again. Kristna's job is organization research and feedback. Nobody in our group in an expert, and we will all contribute towards the process, tasks and big picture. I don't expect that Kristna will be able to know everything, although he has considerable experience interpreting government requirements, so I expect that his contribution to defining the process will be considerable.
Let me spell this out as distinctly as possible: The tasks ahead of us are huge; my goal right now is process. The goal is not even CC or FIPS Validation, it is process. Krishna's job right now is process. He is a facilitator and an organizer. We will all work together to make sure that we answer the questions that Krishna has. Keep in mind what I mean by a small list of TO-Do's. Considering the number of resources we have, a major goal is to simplify the process into manageable chunks. This simplification may result in the process being extended indefinitely but as we work through and improve the process it will be possible for us to attract more resources. Think of this first part as moving up a big hill and starting in low gear!
After he figures that out and publishes it for you and all other volunteers (including himself, you, me, every member of the VM team, every member of the cryptography team, every member of the UI team, every member of the documentation team, and everyone else who isn't even on a team yet), that's when you can really do your job. Krishna will identify the questions that need to be answered, the roadblocks in the way, the direction that the project needs to go, and basically the tasks that need resources assigned to them.
My job right now, as requested by Krishna, is to feed him as much information as possible, and help him identify questions that need to be answered before he can figure out what the top-level tasks will end up being. I expect that he'll consult with you regarding the questions he has; I can provide information from the published documents, but I can't interface with any external organizations (that's a POC function, and I think someone appointed by the Squeak Foundation itself should do that -- which is you).
My task for you would be to help define the big picture but only in very broad strokes. I think that putting together and understanding the process and where we might need to be steered back onto the road and out of a ditch is what you will be very good at. As for actual work instead of steering I would like you to help focus on the actual first task as defined by Krishna. You are right we are waiting for a process and a first task from Krishna. The first task may be something like what are the steps to accomplish the first task. Or what is the process for determining the first task. I know it sounds simple but there is a huge benefit toward organization, and that right now is our goal.
There appears to be some confusion remaining as to what is being required, by whom. The sense that you got from the evaluation organization you spoke with seemed to be that a systemic evaluation included component evaluation, where I'm seeing that there is a political distinction being made by the CSRC at NIST, by the NSA, and by US Code. (I will be happily surprised if this distinction that I'm seeing really isn't there, and that the FIPS validation can occur as part of the CC validation... but I would be remiss if I didn't point out the possibility that the sense you got from the conversation wasn't necessarily the sense that the person who the conversation was with was trying to convey, or that the person who conveyed had a misunderstanding himself.)
Remember: an application may use FIPS-specified cryptographic algorithms, PRNG algorithms, key seeding mechanisms, etc -- but it's not FIPS unless the cryptographic component is validated by an independent testing organization.
Ok understood, but my understanding is FIPS validation of cryptographic components can be done as a separate process, we could have both a system validation and a cryptographic component validations, my understanding is that there is little value to having the individual components validated if the systems as a whole is validated. I could be wrong, but it sounded to me like more money spent for little value.
The design of code and handling of each task will be the responsibility
of
the group with an eye on following the standards as closely as possible
so
that we can achieve CC validation.
Again, which CC protection profile validation are we attempting to achieve? Krishna has identified one that exists, that may or may not be what we are attempting to work toward. One of the roadblocks that exists right now is that not all of us are on the same page as regards eventual destination.
Right this is something we need to decide.
Squeak could meet the CC EAL4+ requirement for FIPS validated cryptography by embedding OpenSSL, or by interfacing directly to the CryptoAPI, and not implementing any cryptography internally. (This would also allow Squeak to be used by the US government now, in low-assurance environments that require only EAL1+.)
Yes and I would agree that this is a subject that we will need to
discuss as
a group.
Yes, not only on the cryptography list, but also on the main Squeak-dev list. It is also probably something that the Squeak Foundation board will have to discuss and agree on.
I disagree here, we can reach out for help when we need to but few people are interested in what we are doing (regrettably). We will decide what we are going to work on, it may not be a consensus decision, and it may not be valuable to everyone but it will get us somewhere that we are not today.
The way I would frame the question is thus: How quickly do we want government agencies to be able to consider Squeak as part of their acquisition strategy? Is it worth doing in multiple phases -- i.e., make it possible now, and then work on progressively more detailed assurance levels until it finally meets the eventual protection profile goal? As an alternative, should we do it in two phases by adding FIPS now, and then meet the eventual Common Criteria validation destination several years down the road, with no intermediate validations? Or, should we just not worry about the government, and only present it to them with the final destination's validation?
I suspect there are other considerations that I'm not thinking about.
These are things we will need to decide.
What is the CC EAL level to which Java and Eclipse have been verified? What protection profiles have they been verified to meet?
EAL4:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com .i
bm.websphere.express.doc/info/exp/ae/rovr_commoncriteria.html
From what I read there, Websphere has been verified to meet EAL4 in a specific configuration. That does not necessarily mean that Java itself has been, nor does it necessarily mean that Eclipse has been.
The standard Websphere configuration is not EAL4 verified -- it takes downloading and faithfully following a 1 meg PDF to deploy it in a CC verified configuration.
Right but this is our goal too! Understand that the value of our work is this document. Our goal is to provide a map to others building applications and deploying them deliver CC validated software. Our goal is not to validate Squeak or to have a validated running implementation it is to allow others to have that. We have to set up a running implementation so that a lab can poke at it, but after that it goes away and what we did to get the system validated becomes that large implementation guide. The goal is the implantation guide and deployed validated commercial Squeak software. We won't be doing the deployment but we might consult with people that want too (to help fund the group!)
Even then, it uses separately-FIPS-validated Java class libraries.
Again I don't think that individual validation is necessary, but I could be wrong. When we are ready to talk to a lab we will bring this up again, if we need individual component validation we will raise money for it at that time.
(I realize that this isn't really a Squeak question, but I am curious why on startup Croquet says, on Windows 2000, that there is no good source of entropy for the random number generator. This is something that should be looked at, if only to make sure that it's not poisoning this effort.)
Andreas mentioned this to me; he is using a primitive call to an OS
level
PRNG as entropy. For Fortuna we need many more sources of entropy then that. I will read through the requirements before starting this
project.
On Windows, the HKLM\Software\Microsoft\Cryptography\Rng\Seed registry key is available, as is the CryptoAPI's RC4-based entropy generator.
Terrific I will look at this more closely to see if it will work. We need 32 separate entropy sources for Fortuna! It will be a fun project! Maybe we could start a list on wiki?
I was asked by the lab I spoke with if we planned on doing individual component validation or system validation. There feeling was that individual component validation is included in system validation so that having each component validated separately was not necessary.
Again, I'm not sure if their interpretation is correct. I'll look at the various interpretations documents and see what I can find out -- but someone at the CSRC may be a better source of information.
OK!
At least, I'm presuming that those two (development of functional code & determinance of packaging requirements) can be parallelized.
My feeling is that we will need to do most of this by ourselves. I will
try
to find more consultants for high level review. I do not expect to
bring in
a lab until we are satisfied that we are very close, except for maybe an initial consultation, or as needed to answer questions if we feel we are
off
track.
Aye.
Thanks again,
-Kyle H
Thanks,
Ron
BINGO!
Ok so now we are on the same page!
I agree with your VM assessment although I will be working towards validating our changes and working them into the main stream, since I can't believe that anyone would not want a secure VM. The biggest argument I expect is about performance, but if we can moderate the impact of cryptography on performance (there will of course be some penalty but newer technologies for VM may help with overall performance), then hopefully the changes we suggest will be acceptable to the community.
Of course documentation, testing and performance evaluations will be very important part of having the community accept our changes.
Ron
-----Original Message----- From: Kyle Hamilton [mailto:aerowolf@gmail.com] Sent: Friday, October 20, 2006 1:57 PM To: Ron@usmedrec.com Cc: Cryptography Team Development List Subject: Re: [Cryptography Team] Common Criteria Documentation...
Hi Ron!
Okay. Now I think we're MUCH closer to understanding.
Krishna did ask me for detail, to be put onto the wiki -- not only related to CC, but also to FIPS. (A separate FIPS certification for the cryptographic component is mandatory if a sysem is to be used in the US government to handle any confidential data, per the Federal Information Security Management Act of 2002. This is where my confusion comes in related to it, but it's something that can be put on hold for a while.)
Your statement is that the immediate goal is the development of the process through which we can meet all criteria necessary for validation. This is perfectly reasonable, especially as the process requirements will be close to the same for whatever validations we go through.
Krishna asked me to put as much detail in the wiki as I can related to functional and process requirements. It is my sense that he wants to design a process to modify Squeak for validation with as little red tape as possible for the people involved, while still adhering to the requirements necessary. (At least, I hope that's his goal. I wouldn't want too much red tape, myself.)
If there are few people outside of the cryptography list who are interested in getting Squeak ready to be validated, then the target may end up taking the form of a separate Monticello package with all of the modifications to the VM classes necessary, and instructions on how to build a CC-conforming VM and systems based on it. (Yay documentation :) ) I don't know, and right now I'm tossing ideas out on the table simply because of that. I'm not the one who's going to determine the final destination, nor the path by which we get there.
So. If the goal is the process, then I'll find everything I can related to the process requirements and put it on the wiki so that you and Krishna can figure out ways that they can be met without imposing too huge an overhead on the volunteers involved. Functional requirements that I find will also go on the wiki (in a separate page), so that they can be distilled into an overall architecture... while presumably still leaving room for individual design and development.
Which seems to be the way that most successful open-source projects do it anyway. :)
-Kyle H
On 10/20/06, Ron Teitelbaum Ron@usmedrec.com wrote:
Hi Kyle,
It looks like we are getting closer, but still slightly off. Let's see
if
we can move more towards each other in our differences.
From: Kyle Hamilton Sent: Friday, October 20, 2006 1:02 AM
On 10/18/06, Ron Teitelbaum Ron@usmedrec.com wrote:
I'm not sure I would put it that way. Let me reword my intention in
my
own
words and see if they match what you are saying. My goal is to
first
set up
an organized plan of attack. I specifically asked Krishna to keep
an
eye on
the larger goal but to provide us with a road map that consists of a
short
list of items that need to be accomplished. We will work on a high
level
feedback mechanism so that we can all see the big picture and where
we
are
in that larger process, but I want to make sure that the current
tasks
are
highlighted, considered carefully, and that the list of To-do's is
short
and
manageable.
Every list of To-do's is made up of a thousand details. If I read this right, you want basically the top and some of the second-level items in the outline, so that it can be distributed to each group... and each group determines what's necessary.
Not quite since there is really only one group. We can work towards reaching out to other groups but only as we identify areas where we need help. I don't believe that we have the resources to do things in
parallel.
I can understand your desire and need to keep it manageable -- you are, essentially, the resource manager (as well as a resource!), and Krishna is the project manager.
Yes.
You need to have a high-level overview of what kinds of resources (people, time, money) are going to be needed, at what points in the process, so that you can make sure that they're allocated properly (and not be surprised later on).
Yes.
Krishna's job, on the other hand, is the more detailed one. This is not a simple process. Each and every single detail needs to be checked and doublechecked -- yes, over time, the details can be fleshed out for each group, but at this point the resource requirements (and the support needed) aren't really known by anyone. He needs as much information as he can get so that over the next month, he can figure out the tasks, figure out what the bullet points must be -- and figure out what resources will be needed for each task.
Now here is where we get off track again. Kristna's job is organization research and feedback. Nobody in our group in an expert, and we will
all
contribute towards the process, tasks and big picture. I don't expect
that
Kristna will be able to know everything, although he has considerable experience interpreting government requirements, so I expect that his contribution to defining the process will be considerable.
Let me spell this out as distinctly as possible: The tasks ahead of us
are
huge; my goal right now is process. The goal is not even CC or FIPS Validation, it is process. Krishna's job right now is process. He is a facilitator and an organizer. We will all work together to make sure
that
we answer the questions that Krishna has. Keep in mind what I mean by a small list of TO-Do's. Considering the number of resources we have, a
major
goal is to simplify the process into manageable chunks. This
simplification
may result in the process being extended indefinitely but as we work
through
and improve the process it will be possible for us to attract more resources. Think of this first part as moving up a big hill and
starting in
low gear!
After he figures that out and publishes it for you and all other volunteers (including himself, you, me, every member of the VM team, every member of the cryptography team, every member of the UI team, every member of the documentation team, and everyone else who isn't even on a team yet), that's when you can really do your job. Krishna will identify the questions that need to be answered, the roadblocks in the way, the direction that the project needs to go, and basically the tasks that need resources assigned to them.
My job right now, as requested by Krishna, is to feed him as much information as possible, and help him identify questions that need to be answered before he can figure out what the top-level tasks will end up being. I expect that he'll consult with you regarding the questions he has; I can provide information from the published documents, but I can't interface with any external organizations (that's a POC function, and I think someone appointed by the Squeak Foundation itself should do that -- which is you).
My task for you would be to help define the big picture but only in very broad strokes. I think that putting together and understanding the
process
and where we might need to be steered back onto the road and out of a
ditch
is what you will be very good at. As for actual work instead of
steering I
would like you to help focus on the actual first task as defined by
Krishna.
You are right we are waiting for a process and a first task from
Krishna.
The first task may be something like what are the steps to accomplish
the
first task. Or what is the process for determining the first task. I
know
it sounds simple but there is a huge benefit toward organization, and
that
right now is our goal.
There appears to be some confusion remaining as to what is being required, by whom. The sense that you got from the evaluation organization you spoke with seemed to be that a systemic evaluation included component evaluation, where I'm seeing that there is a political distinction being made by the CSRC at NIST, by the NSA, and by US Code. (I will be happily surprised if this distinction that I'm seeing really isn't there, and that the FIPS validation can occur as part of the CC validation... but I would be remiss if I didn't point out the possibility that the sense you got from the conversation wasn't necessarily the sense that the person who the conversation was with was trying to convey, or that the person who conveyed had a misunderstanding himself.)
Remember: an application may use FIPS-specified cryptographic algorithms, PRNG algorithms, key seeding mechanisms, etc -- but it's not FIPS unless the cryptographic component is validated by an independent testing organization.
Ok understood, but my understanding is FIPS validation of cryptographic components can be done as a separate process, we could have both a
system
validation and a cryptographic component validations, my understanding
is
that there is little value to having the individual components validated
if
the systems as a whole is validated. I could be wrong, but it sounded
to me
like more money spent for little value.
The design of code and handling of each task will be the
responsibility
of
the group with an eye on following the standards as closely as
possible
so
that we can achieve CC validation.
Again, which CC protection profile validation are we attempting to achieve? Krishna has identified one that exists, that may or may not be what we are attempting to work toward. One of the roadblocks that exists right now is that not all of us are on the same page as regards eventual destination.
Right this is something we need to decide.
Squeak could meet the CC EAL4+ requirement for FIPS validated cryptography by embedding OpenSSL, or by interfacing directly to
the
CryptoAPI, and not implementing any cryptography internally.
(This
would also allow Squeak to be used by the US government now, in low-assurance environments that require only EAL1+.)
Yes and I would agree that this is a subject that we will need to
discuss as
a group.
Yes, not only on the cryptography list, but also on the main Squeak-dev list. It is also probably something that the Squeak Foundation board will have to discuss and agree on.
I disagree here, we can reach out for help when we need to but few
people
are interested in what we are doing (regrettably). We will decide what
we
are going to work on, it may not be a consensus decision, and it may not
be
valuable to everyone but it will get us somewhere that we are not today.
The way I would frame the question is thus: How quickly do we want government agencies to be able to consider Squeak as part of their acquisition strategy? Is it worth doing in multiple phases -- i.e., make it possible now, and then work on progressively more detailed assurance levels until it finally meets the eventual protection profile goal? As an alternative, should we do it in two phases by adding FIPS now, and then meet the eventual Common Criteria validation destination several years down the road, with no intermediate validations? Or, should we just not worry about the government, and only present it to them with the final destination's validation?
I suspect there are other considerations that I'm not thinking about.
These are things we will need to decide.
What is the CC EAL level to which Java and Eclipse have been
verified?
What protection profiles have they been verified to meet?
EAL4:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com
.i
bm.websphere.express.doc/info/exp/ae/rovr_commoncriteria.html
From what I read there, Websphere has been verified to meet EAL4 in a specific configuration. That does not necessarily mean that Java itself has been, nor does it necessarily mean that Eclipse has been.
The standard Websphere configuration is not EAL4 verified -- it takes downloading and faithfully following a 1 meg PDF to deploy it in a CC verified configuration.
Right but this is our goal too! Understand that the value of our work
is
this document. Our goal is to provide a map to others building
applications
and deploying them deliver CC validated software. Our goal is not to validate Squeak or to have a validated running implementation it is to
allow
others to have that. We have to set up a running implementation so that
a
lab can poke at it, but after that it goes away and what we did to get
the
system validated becomes that large implementation guide. The goal is
the
implantation guide and deployed validated commercial Squeak software.
We
won't be doing the deployment but we might consult with people that want
too
(to help fund the group!)
Even then, it uses separately-FIPS-validated Java class libraries.
Again I don't think that individual validation is necessary, but I could
be
wrong. When we are ready to talk to a lab we will bring this up again,
if
we need individual component validation we will raise money for it at
that
time.
(I realize that this isn't really a Squeak question, but I am
curious
why on startup Croquet says, on Windows 2000, that there is no
good
source of entropy for the random number generator. This is
something
that should be looked at, if only to make sure that it's not
poisoning
this effort.)
Andreas mentioned this to me; he is using a primitive call to an OS
level
PRNG as entropy. For Fortuna we need many more sources of entropy
then
that. I will read through the requirements before starting this
project.
On Windows, the HKLM\Software\Microsoft\Cryptography\Rng\Seed registry key is available, as is the CryptoAPI's RC4-based entropy generator.
Terrific I will look at this more closely to see if it will work. We
need
32 separate entropy sources for Fortuna! It will be a fun project!
Maybe
we could start a list on wiki?
I was asked by the lab I spoke with if we planned on doing
individual
component validation or system validation. There feeling was that individual component validation is included in system validation so
that
having each component validated separately was not necessary.
Again, I'm not sure if their interpretation is correct. I'll look at the various interpretations documents and see what I can find out -- but someone at the CSRC may be a better source of information.
OK!
At least, I'm presuming that those two (development of functional
code
& determinance of packaging requirements) can be parallelized.
My feeling is that we will need to do most of this by ourselves. I
will
try
to find more consultants for high level review. I do not expect to
bring in
a lab until we are satisfied that we are very close, except for
maybe an
initial consultation, or as needed to answer questions if we feel we
are
off
track.
Aye.
Thanks again,
-Kyle H
Thanks,
Ron
--
-Kyle H
cryptography@lists.squeakfoundation.org
-
Craig Latta -
Krishna Sankar -
Kyle Hamilton -
Ron Teitelbaum