[Cryptography Team] FIPS OpenSSL Crypto++ and CryptoAPI

[Ron Teitelbaum]

Hi Kyle, 

Welcome again to the team.  I am very happy to have you as part of our
validation effort.  I am looking forward to working with you to meet your
goals and I'm very interested in learning more about what you are working
on.  I hope that we can all learn more about the validation process and that
we can help teach others.

Here is a link to my original email after talking to the lab:
http://lists.squeakfoundation.org/pipermail/cryptography/2006-July/000211.ht
ml I spoke with J. Mark Braga of SAIC CMTL http://www.saic.com/infosec/cmtl/
they were very clear that 140-2 - level 2 validation is what most software
systems work towards.  There is a possibility that I misunderstood or that
the -2 and level 2 got confused, but that seems unlikely since, as you said,
140-1 doesn't apply.  I guess my understanding was that the security policy
needed to include standards that must be followed for someone else to have a
140-2 level 2 validated system derived from our code.  I also understood
that we needed a reference implementation that exhibited these standards,
but I figured we would set that up somewhere once we needed too.  In order
to support the physical requirement I figured we needed to say in our
security policy that the server needed to be in a locked room with a lock
pick resistant door, and those that have a key need to have clearance
through a process that includes...  I have no idea what to think about
TCP/IP access and I guess if that completely invalidates level 2 then I
can't imagine that most systems used comply with level 2 validation (unless
TCP/IP in a secure WAN is acceptable).  

We need more clarity around this issue, but it doesn't have to happen now,
first things first.  I'm sure there is a lot more we will learn as we go.

You goals for helping to increase the usage of cryptography fit very nicely
with the stated goals of this team.  Your p2p project opens up some very
interesting questions as to security since it is the client that needs to be
secured and the hardware is potentially in the hands of the attacker.  I am
also very interested in this question and I hope that we can spend some time
discussing this, either in the group or off line.

Welcome to the team!

Ron Teitelbaum
Squeak Cryptography Team Leader


> -----Original Message-----
> From: Kyle Hamilton [mailto:aerowolf at gmail.com]
> Sent: Thursday, October 12, 2006 4:36 PM
> To: Ron at usmedrec.com; Cryptography Team Development List
> Subject: Re: [Cryptography Team] FIPS OpenSSL Crypto++ and CryptoAPI
> 
> Hello, Ron and everyone!
> 
> I'll reply to your concerns in order; I just woke up, but talking
> about cryptography and implementation always gets me thinking more
> effectively. :)
> 
> I've been discussing the FIPS effort with the OpenSSL development
> team, when they have any time to work on it, and the issues with its
> being made "not available for procurement" are related to its security
> boundary and cryptographically-signed container.  A very few functions
> that are security-related were not placed inside the signed container,
> and that raised concerns at the lab.  (Considering that the container
> was created basically within the last 3 months of the validation
> effort, I can't say that I'm really surprised.)
> 
> However, and I cannot stress this enough, OpenSSL-FIPS 1.0 retains its
> validation for people who have already received the source, and can
> still be used to build valid binaries for customers.
> 
> To my understanding, the 1.1 effort is primarily an effort to more
> appropriately define and defend the security boundary.
> 
> Now, as for the level of validation:  Please note that it's not
> "certification", it's "validation".  When dealing with the US
> government, at least, they're very picky about their terminology.
> Certificates of validation are issued by NIST after an independent
> laboratory verifies that a given system operates the way that it is
> intended to, according to the NIST/FIPS testing plan.
> 
> As for the level: OpenSSL is also level 1.  It don't believe it's
> possible for any pure-software system (specifically, "multi-chip
> standalone" system) to receive anything higher than a level 1
> validation, because the communications between the chips can be
> tampered with.  For a level 2 or higher validation I believe it is
> necessary to add tamper-resistance to the hardware.  (I can't be sure,
> though, because the various links that supposedly mention what the
> requirements are no longer work.  I'll have to go to a depository
> library and pull the appropriate documents; it'll probably be easier
> than finding them on the web.  However, I did find this:
> http://niap.bahialab.com/pp/ci_manuals.cfm which may or may not be of
> use.  Low Robustness Targets of Evaluation may include software, and
> require some action on the part of the IT staff at field
> implementation; Medium Robustness Targets of Evaluation require
> hardware.)
> 
> If you look at Certificate 405 at
> http://csrc.nist.gov/cryptval/140-1/1401val2004.htm#405 , you'll see
> that even Microsoft's kernel-mode FIPS.SYS driver is 140-2 level 1.
> Even though it supports role-based security, it doesn't exhibit
> tamper-evidence (it's possible to restore a backup and remove all
> traces of tampering).
> 
> Now, a note about FIPS 140-1 versus FIPS 140-2.  140-1 is no longer
> available for new validations nor product procurements, though
> products that use them may still be used.  140-2 is the current
> version of the FIPS that cryptographic modules must adhere to.  The
> manuals for how a module is tested are on http://csrc.nist.gov/, as
> well as the functional requirements for startup and environment
> validation.
> 
> (Also, please note: Windows only achieves C2 certification when it's
> unplugged from the network.  TCP/IP makes C2 compliance impossible, as
> there are covert channels within the protocol itself.)
> 
> For reference, what laboratory did you speak to that stated that level
> 2 is the most common that is worked toward by software?  The
> requirements for level 2 cannot be met by software without the help of
> hardware.
> 
> We could certainly use the CryptoAPI on Windows, and in fact for PRNG
> cryptographic robustness we must (unless we want to build a new
> entropy-gathering system that we then pass through a FIPS-specified
> PRNG function).  However, as a cross-platform project, I must point
> out that introducing platform specific code will only make things more
> difficult.  (Then again, considering how difficult it is to build
> OpenSSL-FIPS on Windows, and the current impossibility of building it
> using standard Microsoft toolchains, we may need to create a
> platform-independent abstraction in any case.)
> 
> Anyway, hi!  My name is Kyle Hamilton.  I am a hobbyist security
> researcher who is attempting to build a general-purpose
> strongly-authenticable and strongly-encrypted peer-to-peer wireless
> networking system.  I am envisioning emergency response crews (FEMA,
> EMTs, civilian emergency response crews, and police forces) and
> perhaps military combat units (as AES-256 has been specified by the
> NSA as being sufficient to protect "secret" classified data) utilizing
> this; this is why I am so interested in FIPS validation for my final
> design.  I am a contributor to the RSA Labs Cryptography FAQ, and
> worked at Intel as a contractor on SSL acceleration in the mid 1990s.
> (One notable quote from my first interview there: "There is absolutely
> nothing on your resume to show that you have anywhere near the level
> of knowledge of cryptography that you have demonstrated today.")
> 
> What I want to get out of the Squeak project here is to make sure that
> strong cryptography is available to many more people than just those
> who spend the time working on it.  I'm getting involved with a p2p
> authentication system design being developed for OpenSSL 0.9.7g in a
> software called RetroShare, and I think that since IPsec turned out to
> be a huge flop, it's probably time for application developers to take
> cryptographic implementation into their own hands.
> 
> -Kyle H
> 
> On 10/12/06, Ron Teitelbaum <Ron at usmedrec.com> wrote:
> > 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