[Cryptography Team] Common Criteria Documentation...

Kyle Hamilton aerowolf at gmail.com
Wed Oct 18 03:25:47 UTC 2006 

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 at 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 at lists.squeakfoundation.org
> > [mailto:cryptography-bounces at 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 at 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 at lists.squeakfoundation.org
> > > > [mailto:cryptography-bounces at lists.squeakfoundation.org] On
> > > > Behalf Of Krishna Sankar
> > > > Sent: Tuesday, October 17, 2006 9:46 AM
> > > > To: Ron at 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 at lists.squeakfoundation.org
> > > > > [mailto:cryptography-bounces at 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 at lists.squeakfoundation.org is our mailing list.
> > > > >
> > > > > Ron
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: cryptography-bounces at lists.squeakfoundation.org
> > > > > > [mailto:cryptography-bounces at 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 at lists.squeakfoundation.org
> > > > > > > [mailto:cryptography-bounces at 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 at lists.squeakfoundation.org
> > > > > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > > > > > ptography
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Cryptography mailing list
> > > > > > Cryptography at lists.squeakfoundation.org
> > > > > >
> > > > >
> > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
> > > > > > y
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Cryptography mailing list
> > > > > Cryptography at lists.squeakfoundation.org
> > > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > > ptography
> > > > >
> > > >
> > > > _______________________________________________
> > > > Cryptography mailing list
> > > > Cryptography at lists.squeakfoundation.org
> > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > ptography
> > > >
> > >
> > > _______________________________________________
> > > Cryptography mailing list
> > > Cryptography at lists.squeakfoundation.org
> > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
> > >
> >
> >
> > --
> >
> > -Kyle H
> > _______________________________________________
> > Cryptography mailing list
> > Cryptography at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>
>
> _______________________________________________
> Cryptography mailing list
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>


-- 

-Kyle H

More information about the Cryptography mailing list