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

[Isaac Hailperin]

Steve,

thank you for alerting us.
Do I understand correctly that by "platform", not a general OS (like "Linux", "Solaris") on a specific hardware (sparc, x86, ...) is meant, but a very specific distribution release, like "Ubuntu 14.04", or "CentOS 7.0", on e.g. x86? This would mean that there would be no fips compliant openssl build possible on e.g. a future "CentOS 8.1"?

We are currently using the fips module on Solaris 10, and have plans to use it on Linux, probably RHEL 7.X, but depending on the time in the future, that could well be RHEL 8.X.

Isaac

-----Original Message-----
From: openssl-users [mailto:openssl-us...@openssl.org] On Behalf Of Steve Marquess
Sent: Mittwoch, 25. Februar 2015 15:08
To: openss...@openssl.org
Subject: [openssl-users] End of the line for the OpenSSL FIPS Object Module?

As always, if you don't know or care what FIPS 140-2 is count yourself very, very lucky and move on.

The open source based OpenSSL FIPS module validations now date back over a decade, a period during which we've encountered many challenges.
We have recently hit an issue that is apparently inconsequential on its face, but which threatens to bring an end to the era of the open source validated module. This is a situation that reminds me of the old "for want of a nail..." ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail).

Tedious details can be found here:

http://openssl.com/fips/hostage.html

The short take is that for now at least the OpenSSL FIPS Object Module v2.0, certificate #1747, can no longer be updated to include new platforms. This development also wrecks the already marginal economics of tentative plans for a new open source based validation to succeed the current #1747. So, the #1747 validation may be the last of the collaborative open source FIPS modules.

If you are a stakeholder currently using the OpenSSL FIPS module, or with a desire to use it or successor modules (either directly or as the basis for a "private label" validation), this is the time to speak up.
Feel free to contact me directly for specific suggestions or to coordinate with other stakeholders.

-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
marq...@opensslfoundation.com
marq...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Steve Marquess]

On 02/26/2015 07:04 AM, Isaac Hailperin wrote:
> Steve,
>
> thank you for alerting us. Do I understand correctly that by
> "platform", not a general OS (like "Linux", "Solaris") on a specific
> hardware (sparc, x86, ...) is meant, but a very specific distribution
> release, like "Ubuntu 14.04", or "CentOS 7.0", on e.g. x86? This
> would mean that there would be no fips compliant openssl build
> possible on e.g. a future "CentOS 8.1"?

Note the pedantically correct term is "FIPS 140-2 validated", not "FIPS
compliant". But yes, correct.

> We are currently using the fips module on Solaris 10, and have plans
> to use it on Linux, probably RHEL 7.X, but depending on the time in
> the future, that could well be RHEL 8.X.

"Platform" -- technically "Operational Environment" or "OE" -- is a
rather peculiar concept in the context of FIPS 140-2 validations, and
unfortunately one that has never been clearly defined (also one that
changes over time due to ever shifting CMPV "guidance").

Based on observation and the conventional wisdom of the FIPS validation
community, I'll attempt an oversimplified, unofficial,
non-authoritative, non-definitive, and thoroughly worthless definition:

For Level 1 validations, very roughly speaking, an OE is an operating
system name (e.g. "Ubuntu") and the first two dot-rev levels of the
version number (e.g. "14.04" for "14.04.01", "14.04.02", etc.), *and* a
"processor architecture". All x86-64 processors with AES-NI (again
roughly speaking) are the same "processor architecture", as are all
those without (and ditto for ARMv7 and NEON).

32 and 64 code comprise separate "platforms", and a given OS+OS
version+processor architecture+address bit length "platform" running
"bare-iron" constitutes a different "platform" from the exact same
software+hardware combination running virtualized under each distinct
brand name and version of hypervisor environment. So for instance

Ubuntu 14.04 64bit on Intel Xeon E3-1220 under Vmware ESXi 5.1

is a different "platform" from

Ubuntu 14.04 64bit on Intel Xeon E3-1220 under Vmware ESXi 5.5

I've left out a number of known exceptions, complications, and anomalies...

[Jeffrey Walton]

Hi Steve,

I read the 'The FIPS 140-2 "Hostage" Issue' page. Its not clear to me
what the problem is, or how OpenSSL is a hostage.

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?

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?

Jeff

On Wed, Feb 25, 2015 at 9:08 AM, Steve Marquess <marq...@openssl.com> wrote:
> As always, if you don't know or care what FIPS 140-2 is count yourself
> very, very lucky and move on.
>
> The open source based OpenSSL FIPS module validations now date back over
> a decade, a period during which we've encountered many challenges.
> We have recently hit an issue that is apparently inconsequential on its
> face, but which threatens to bring an end to the era of the open source
> validated module. This is a situation that reminds me of the old "for
> want of a nail..." ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail).
>
> Tedious details can be found here:
>
> http://openssl.com/fips/hostage.html
>
> The short take is that for now at least the OpenSSL FIPS Object Module
> v2.0, certificate #1747, can no longer be updated to include new
> platforms. This development also wrecks the already marginal economics
> of tentative plans for a new open source based validation to succeed the
> current #1747. So, the #1747 validation may be the last of the
> collaborative open source FIPS modules.
>
> If you are a stakeholder currently using the OpenSSL FIPS module, or
> with a desire to use it or successor modules (either directly or as the
> basis for a "private label" validation), this is the time to speak up.
> Feel free to contact me directly for specific suggestions or to
> coordinate with other stakeholders.
>
> -Steve M.

[Jakob Bohm]

I think it was clear enough:

NIST/NSA/CMVP is demanding that OpenSSL change the
definition of *already* "validated" platforms before they
will allow OpenSSL to add new platforms.

But changing those definitions would invalidate existing
government contracts for delivery of products that used
the OpenSSL FIPS module on those platforms, so the users
that actually need the FIPS validation will be hurt
either way.

For example, if company X has an existing contract where
they promise that the foo system they delivered to some
US Government agency uses only crypto code which was
validated for "Red Hat Enterprise Linux 7.0 (x86_64)
running on VmWare ESX", then if OpenSSL obeys the
demand to change the definition to read "Red Hat
Enterprise Linux 7.0 (x86_64) running on VmWare ESX
5.1", then company X would suddenly be unable to
fulfill their contract, which may even be a criminal
offense.  But if OpenSSL refuses to change the
definition, OpenSSL cannot deliver to company X a
new validation for "Apple OS/X 10.8 (x86_64) running
on raw Apple hardware", so company X cannot get a new
government contract to deliver for that platform, and
neither can anybody else.

So currently, OpenSSL's realistic options are:

A. Wait for someone to convince the US Government to
  drop this retroactive requirement.
B. Start over with a new validation for a new FIPS
  module version 3, which would have to be modified
  to meet other new demands, which didn't exist when
  FIPS module version 2 was originally submitted.
   This would involve 2 variants of the FIPS interface
  code in OpenSSL 1.0.3, lots of new code and a very
  very expensive bill to get the code validated all
  over again.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 

[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
marq...@opensslfoundation.com
marq...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

[Steve Marquess]

On 02/27/2015 01:56 AM, Jakob Bohm wrote:
> I think it was clear enough:
>
> NIST/NSA/CMVP is demanding that OpenSSL change the

> definition of*already* "validated" platforms before they
> will allow OpenSSL to addnew platforms.

>
> But changing those definitions would invalidate existing

> governmentcontracts for delivery of products that used
> the OpenSSL FIPS moduleon those platforms, so the users
> that actually need the FIPS validationwill be hurt

> either way.
>
> For example, if company X has an existing contract where

> they promisethat the foo system they delivered to some
> US Government agencyuses only crypto code which was
> validated for "Red Hat EnterpriseLinux 7.0 (x86_64)

> running on VmWare ESX", then if OpenSSL obeysthe
> demand to change the definition to read "Red Hat

> EnterpriseLinux 7.0 (x86_64) running on VmWare ESX
> 5.1", then company Xwould suddenly be unable to
> fulfill their contract, which may evenbe a criminal

> offense. But if OpenSSL refuses to change the
> definition, OpenSSL cannot deliver to company X a

> new validationfor "Apple OS/X 10.8 (x86_64) running
> on raw Apple hardware",so company X cannot get a new
> government contract to deliver forthat platform, and
> neither can anybody else.

Jakob, you nailed it. Do you mind if I add that explanation as a
footnote (with attribution)?

I've spent so long in the government arena I forget that not everyone
realizes how arduous the procurement process can be, or how rigid and
inflexible.

>
> So currently, OpenSSL's realistic options are:
>
> A. Wait for someone to convince the US Government to
> drop thisretroactive requirement.

Which we are doing, and I do expect this latest retroactive requirement
to be rescinded eventually (as happened before in early 2014). However,
once again the delay has a severe short term cost for the sponsors of
pending new platforms.

> B. Start over with a new validation for a new FIPS

> module version 3, whichwould have to be modified
> to meet other new demands, whichdidn't exist when

> FIPS module version 2 was originally submitted.

We do want to begin a new validation to address all the new requirements
that have accumulated since the #1747 validation was awarded in 2012.
But, while platform sponsors are easy to find, sponsors for the big pain
and big bucks of new validations are not.

We *may* have such sponsorship, at long last, but both we and those
sponsor(s) realize that our plans for that new validation have assumed
that we would be able to extend it indefinitely with change letter
updates (as has traditionally been the case). With that assumption now
in doubt the validation effort becomes economically infeasible for OSF,
as we'll take a loss on the validation itself that could only be
recouped via subsequent change letters. Likewise, the sponsor(s) had
planned on leveraging their substantial investment over time by adding
new platforms as needed.

> This would involve 2 variants of the FIPS interface

> code in OpenSSL1.0.3, lots of new code and a very

> very expensive bill to get thecode validated all
> over again.

Very expensive indeed -- well into six figures -- but the platform
validation costs are typically spread over a large number of platform
sponsors. Each prospective platform sponsor is reminded that if they are
willing to wait long enough some other sponsor may do that platform for
them; but I've found that the platform sponsors are usually delighted to
have the option of paying themselves for a platform validation now
rather than waiting indefinitely. Those sponsors usually have pending
sales that easily justify the platform validation costs.

The hard part has always been funding the initial new validation.