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