[Cryptography Team] FIPS OpenSSL Crypto++ and CryptoAPI

[Kyle Hamilton]

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