[Cryptography Team] Common Criteria Documentation...

[Kyle Hamilton]

On 10/18/06, Ron Teitelbaum <Ron at 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