[Cryptography Team] Common Criteria Documentation...

[Ron Teitelbaum]

Hey Kyle,

> From: Kyle Hamilton
> Sent: Wednesday, October 18, 2006 4:49 PM
> 
> Hey, Ron!
> 
> On 10/18/06, Ron Teitelbaum <Ron at 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