[Cryptography Team] Common Criteria Documentation...

[Kyle Hamilton]

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?

>  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