[openssl-users] End of the line for the OpenSSL FIPS Object Module?

[Steve Marquess]

On 02/26/2015 09:24 PM, Jeffrey Walton wrote:
> Hi Steve,
> 
> I read the 'The FIPS 140-2 "Hostage" Issue' page. Its not clear to me
> what the problem is, ...

I have failed miserably in my objective then, as that web page is an
attempt to explain a complex and important issue. It's always a struggle
to succinctly explain the Alice-in-Wonderland world of FIPS 140-2 to
those haven't spent way too many years exposed to it.

> ...or how OpenSSL is a hostage.

The hostages are those vendors (such as Vendor "X") who have funded past
platform validations, or those vendors (such as Vendor "Y") who would
like to add new platforms. We were put in the painful position of
sacrificing one set of hostages or the other.

> I was looking under "The New Requirement" for a statement of the
> problem (assuming the new requirement is causing the problem), but its
> escaping me (forgive my ignorance). I think the "The New Requirement "
> section is bogged down with some background information, which is
> masking out the statement being made about the problem.
> 
> If its "... the change that is being demanded is that we supply
> explicit version numbers for the hypervisor based platforms, so for
> instance an existing platform", then why is that a problem?

I discuss that in the last three paragraphs of section 3, which I've
re-read just now. Perhaps I should elaborate more on the fine print and
process issues with government procurement paperwork (which may not be
fully appreciated by those who haven't suffered though it). Or perhaps I
should expand the penultimate paragraph to emphasize that vendor "X" and
"Y" paid money to have platforms added to the OpenSSL FIPS module, and
that as with all such sponsors we try to respect those investments?

> How is virtualization a problem? (I know real problems exist in
> virtualized environments, so PRNGs can suffer. We had one appliance
> vendor tell us to do the "link /dev/random to /dev/urandom trick"
> (sigh...)).
> 
> Can't that be worked around by having vendors provide real iron? (Most
> validated platforms appear to be real iron, so it seems nothing has
> changed to me).
> 
> Is it a problem on mobile platforms?
> 
> How is it holding OpenSSL hostage?
> 
> Can you provide the executive summary here?

Hmmm...

I'm at a bit of a loss here and find myself tempted to just repeat what
is already there. I will try to say something different here:

Many companies -- hundreds of them -- have used the OpenSSL FIPS modules
at little or no cost. That was the intent, that is open source goodness.

The validated module is generally useful to an end user only to the
extent that it includes "platforms" of interest to that end user.
"Platforms" can (or could) be added to existing validations relatively
inexpensively, and once added become accessible to everyone. More open
source goodness.

Those validations are difficult and expensive. They have to be paid for
somehow. The bulk of the funding has come from the "change letter"
updates that add new platforms. The OpenSSL FIPS module validations have
thus largely been "self funded" by the community of users.

The CMVP continually changes the requirements for new validations, but
until recently has not retroactively imposed crippling changes on
existing validations. They have started to do so, twice now in 12
months, preventing the addition of new platforms.

If new platforms cannot be added to those hard-won validations, the
overall utility to the end user community is greatly reduced. Even
worse, the pursuit of new validations becomes economically infeasible.

I'm open to suggestions on improving that web page for the TL;DR crowd.
"Make it clearer" may not be enough as I've already attempted and failed
at that.  Specific suggested edits perhaps?

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc