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