[Cryptography Team] FIPS OpenSSL Crypto++ and CryptoAPI

Thu Oct 12 13:23:25 UTC 2006

Hi Kyle and ALL,

First welcome to the team!  I've been following OpenSSL and I really hope
that they solve their problems and receive certification.  We'll have to
keep our eyes on it.  From news reports it appears that vendors of
cryptographic software are the cause of the suspension.  The question now is
how well the lab they are working with can make the case for certification
against such powerful objections.  I'm hoping since they have moved so far
and since they have some corporate funding, they will succeed.  

I'm looking at crypto++ thank you for the link.  I noticed that their
certification is level 1.  When I was discussing this with the lab they were
suggesting a level 2 certification: 

The different levels within the standard provide different levels of
security and in the higher levels, have different documentation
requirements.

Level 1: The lowest level of security. No physical security mechanisms are
required in the module beyond the requirement for production-grade
equipment.

Level 2: Tamper evident physical security or pick resistant locks. Level 2
provides for role-based authentication. It allows software cryptography in
multi-user timeshared systems when used in conjunction with a C2 or
equivalent trusted operating system.

Level 3: Tamper resistant physical security. Level 3 provides for
identity-based authentication.

Level 4: Physical security provides an envelope of protection around the
cryptographic module. Also protects against fluctuations in the production
environment.

They said that level 2 is the most common level for cryptographic software.
I wonder how well the level 1 software is accepted, and how much easier it
is to get?  It is definitely something to consider.  I think that OpenSSL is
working towards level 2.

The major question here is the platform.  IF we want to develop for binaries
that are only for a windows platform, then we could skip the binaries
altogether and just use CryptoAPI since it comes with the operating system
and is also FIPS 140-2 certified (although I have not read the security
policy to know how difficult building 140-2 certified code is).

If this team is interested in a Windows platform certification please speak
up.  If we want to go with windows as a first cut then let's decide to do
that.  My major concern is that most people will be looking to deploy the
software as a server platform and will be looking for a *nix platform.
Personally my interest IS Windows since my goal is to deploy secure clients
not servers, but I don't want my personal needs to effect the group
(especially without saying so specifically).

Again welcome to the group!  Did you want to tell us about your experience
and what you are looking to get from this group?

Ron Teitelbaum
Cryptography Team Leader

> -----Original Message-----
> From: cryptography-bounces at lists.squeakfoundation.org
> [mailto:cryptography-bounces at lists.squeakfoundation.org] On Behalf Of Kyle
> Hamilton
> Sent: Wednesday, October 11, 2006 10:49 PM
> To: Ron at usmedrec.com; Cryptography Team Development List
> Subject: Re: [Cryptography Team] Re: [Newbies] [ANN]
> SqueakCryptographyCertification Validation Officer
> 
> OpenSSL's situation is rather interesting.  The OpenSSL FIPS 1.0 code
> is not available for procurement, but people/companies who already
> have copies are allowed to use it and it retains its validation.  See
> http://oss-institute.org/index.php?option=content&task=view&id=166&Itemid=
> for information (it was mistakenly listed as "revoked", but it is now
> properly marked as "not available":
> http://csrc.nist.gov/cryptval/140-1/1401val2006.htm , certificate
> number 642).
> 
> The other package that I'm thinking of (for Windows) is Crypto++,
> available at http://www.eskimo.com/~weidai/cryptlib.html .
> (Certificate numbers 343 and 562, since there are two different
> versions -- 343 refers to the VC++ 6.0 version, 562 refers to the
> VC++.Net version.)
> 
> I wonder... could the squeak VM have a public key which validates a
> signature on the crypto code whenever an object derived from that code
> is accessed?  Or can the code be made immutable in the VM itself?
> 
> -Kyle H
> 
> On 10/11/06, Ron Teitelbaum <Ron at usmedrec.com> wrote:
> > Hi Kyle,
> >
> > I discussed this with the certification lab that I spoke too.  It is a
> very
> > interesting question and one that we will need to address when it is
> time to
> > do the actual certification.  I know that the common criteria is less
> > strict, and that is where we are focusing now.  There are a number of
> ways
> > that we can ensure that the code is not modifiable, including coding
> signing
> > the VM, removing the compiler, crc checking the code before it runs,
> etc.  I
> > agree with you that this is going to be an interesting challenge, and it
> > will be expensive process once we get to the point when we think we are
> > secure the code and the VM and can pass the CC.  But I also feel that
> having
> > the certification would be a very good thing for Open Source in general,
> so
> > it's a path worth going down.  The lab thought that it would be
> difficult
> > also but they believed it was possible.  I planned to discuss this with
> the
> > lab that worked with OpenSSL but after realizing how much work there was
> > left to do before working with a lab, I figured it could wait.  If they
> > succeed then it makes it easier for us.
> >
> > One of the tenants I've been working under is Good Enough Security.  The
> > idea is that if we try to build the perfect system we would find it a
> task
> > that is so daunting that we would never try.  If we try to make
> incremental
> > improvements using the best information that we can find, working with
> the
> > best possible people, and going through some of the certification
> processes,
> > even if we don't succeed, we make Squeak better, and more secure, and
> more
> > likely that businesses and developers will comfortably adopt Squeak.
> >
> > My understanding of OpenSSL was that they had their certification but it
> was
> > pulled, they are working to restore that certification now, and they
> have
> > passed the lab stage and are waiting again for the government.
> >
> > One of the other things to consider that I have mentioned already is
> that
> > Microsoft CryptoAPI is FIPS certified.  It is possible that we could
> attach
> > to that and develop Squeak systems that are also certified, but I
> haven't
> > read through the security policy document thoroughly enough to know how
> > difficult that would be.
> >
> > What other package where you thinking of?
> >
> > Hope that helps!
> >
> > Ron Teitelbaum
> > Squeak Cryptography Team Leader
> >
> > > From: Kyle Hamilton
> > > Sent: Wednesday, October 11, 2006 6:05 PM
> > >
> > > Welcome, Krishna!
> > >
> > > In the grand scheme of things, how can the integrity of the
> > > cryptographic component module be verifiably maintained in Squeak?
> > > Because of the NIST/FIPS requirement of a security boundary, the
> > > implementation must be an immutable "black box" -- put data in, get
> > > data out.
> > >
> > > OpenSSL has a FIPS-validated component (no longer available for
> > > obtainment, but people who obtained it before it was made
> > > no-longer-available) that would operate in the context of an extension
> > > to the interpreter.  [They're working on a follow-up validation for a
> > > to-be-made-available version of the library.]  There is also at least
> > > one FIPS-validated, freely-available module available for Windows
> > > other than OpenSSL.
> > >
> > > I bring this up only because I can't see how such a black box could be
> > > created (and its internal state verifiable at all times) unless it's
> > > not written within the Squeak environment itself.  There isn't any
> > > means that I know of "sealing" classes and preventing data from being
> > > examined -- thus there isn't any means of enforcing a "black box"
> > > boundary the way that FIPS requires.
> > >
> > > Any thoughts on the matter?  Anyone?
> > >
> > > -Kyle H
> > >
> > > On 10/11/06, Ron Teitelbaum <Ron at usmedrec.com> wrote:
> > > >
> > > > Krishna Sankar is joining our team as the new Squeak Cryptography
> > > > Certification Validation Officer.
> > > >
> > > _______________________________________________
> > > 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
> _______________________________________________
> Cryptography mailing list
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography