[Cryptography Team] Common Criteria Documentation...

[Krishna Sankar]

Kyle,

	I was going to reply to the good e-mail exchanges, but Ron has
articulated well what ever good things I had to say ! Anyway, am going to
harvest a task list out of your detailed e-mails. Pl keep on digging into
the docs and add notes to the Wiki. Let us first internalize the various
aspects of this beast and at some point (most probably in a month or so)
distill a set of tasks to begin.

Cheers
<k/>

> -----Original Message-----
> From: cryptography-bounces at lists.squeakfoundation.org 
> [mailto:cryptography-bounces at lists.squeakfoundation.org] On 
> Behalf Of Kyle Hamilton
> Sent: Wednesday, October 18, 2006 1:49 PM
> To: Ron at usmedrec.com; Cryptography Team Development List
> Subject: Re: [Cryptography Team] Common Criteria Documentation...
> 
> 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
> _______________________________________________
> Cryptography mailing list
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> ptography
>