[Cryptography Team] Todays Meeting update

[Ron Teitelbaum]

Hi All,

I had a very nice meeting with someone that was responsible for CC and FIPS
at Mozilla.  

I left the meeting with a better understanding of what we need to do.  Here
are my notes:

FIPS 140-2 was originally developed as a hardware specification.  Many of
the requirements for FIPS 140-2 software validation still resemble a
hardware implementation. 
	
The basics of 140-2 are:
       
1) Module validation:  Do the modules do what they are supposed to do.
There are a number of other validations for specific algorithms that we may
want to do.
2) FIPS Mode of Operation: Which requires that a user authenticate to the
module before it performs any operations.  This is like a smartcard or some
such hardware implementation.  The Trusted Computing Base would also do a
self check on startUp.
3) low level / high level algorithm separation: Make sure that the
algorithms are properly separated with in the OSI levels.
4) Since we are software and potentially multiuser we would need FIPS 140-2
level 2 validation.

The most difficult part of FIPS is the security document.  

We may want to review openSSL and integrate that or NSS into squeak for
people that have to have an FIPS validated system.  This would remove our
need to be validated, and shift our job to interpreting and implementing
external modules properly.  

OpenSSL solved the problem of code isolation, since they allow both separate
lib calls and imbedding the library into your application, by setting up a
chain of custody which defines how to verify the code has not changed from
Authors to end users.   This doesn't seem to prevent malware from changing
bytes but this may not be required for FIPS validation.  We should look more
closely at OpenSSL's documentation.

Documentation of all modules is also needed.

Common Criteria.

It seems to me that there is little use for us to proceed with CC.  CC is
more like a system evaluation.  They even call it a system evaluation.  The
evaluation has different levels we would probably want 2 or 3 but in order
to have something to validate we would actually need to write a system.  

An example of something that would be validated is an Operating System.  The
operating system requires user authentication, Access control like ACL's,
resource partitioning ...  In this example if the user is required to enter
a password and the operating system says it needs n letters, can only be
entered 3 times before being inactivated, and needs to be changed montly.
Then this would be part of the Protection Profile that is already written
for operating systems.  If there is no current Protection Profile for your
system you can either write you own, and submit it for consideration of all
systems like yours or you can write a Security Target Document which
explains just what your system is doing.  Plus there are the controls over
the development environment and library.

This "what" your system is doing is what would be evaluated.    We may want
to review the Java CC evaluation but it seems to me that we do not have
standard authentication, acl's ...  We may want to write some of those
pieces for people to use, but until we have them we should probably be
focusing on FIPS 140-2.  I'm sorry I didn't understand the distinction
earlier.  

Also CC validation runs around US$200K.  FIPS can be between US$40K -
US$100K

I'm told that if we want to do CC then we should look into foreign labs
since CC is international and a validation from say the EU would be valid in
the US.  Apparently Oracle saved a bundle doing this.

So I'm scheduling a follow up meeting with someone else that I was
introduced too that does is working with a lab to do FIPS Validation for
NSS.  My interest is in how we can get enough of a direction to get things
moving on our own, suggestions on selecting a lab, and what we can expect.
There is nothing like practical experience.  I'm considering forming our own
Foundation and doing some fundraising to cover our costs, so we will need to
show longevity and commitment to encourage investment.  Until that time we
need to make sure we are on the right path.

Comments are welcome,

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists 
Ron at USMedRec.com 
Squeak Cryptography Team Leader