[openssl-users] FIPS 140-2 X9.31 RNG transition ... still in transition

[Steve Marquess]

I'm getting private queries about the status of the OpenSSL FIPS Object
Module v2.0 (the "OpenSSL FIPS module") which I'll answer here for everyone.

As always, if you don't know or care what I'm talking about then run for
high ground lest you trip and fall down the rabbit hole...

The OpenSSL FIPS module is (very confusingly) covered by three nominally
separate validations, #1747, #2398, #2473.

It used to be that validations lived forever. Recently the CMVP has
introduced two policy changes that can kill extant validations (see
http://csrc.nist.gov/groups/STM/cmvp/notices.html, under headings
"validation sunsetting policy" and "X9.31 RNG transition".

One is expiration of validations that haven't been updated in five
years, beginning in 2017; not a factor for any validation yet and moot
for the OpenSSL FIPS module validations for a few years still (as those
tend to be updated frequently).

The other is the "RNG transition" of a large class of validations,
including all the OpenSSL and OpenSSL derived ones, that will kill (has
killed) validations not updated by a week ago. Those deceased
validations can be found at:

  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-historical.htm

Note there are a lot of them, including the older OpenSSL open source
based validations (#1051 and prior).

What about the current OpenSSL FIPS module, which is validation(s)
#1747/#2398/#2473? Well, the paperwork for updating those three
validations (said update consisting of wordsmithing only, no software
changes) was submitted at the same time. But, as so frequently happens
those very similar submissions encountered different receptions.

Two of the submissions have been approved, for #1747 and #2473. The one
for #2398 is still pending. The CMVP has left that validation in the
active validation list, with the notation "This module is in process for
the RNG transition.". So the #2398 validation is in limbo at present,
waiting for CMVP action.

Since the OpenSSL FIPS module is represented by all three validations,
it is in a limbo of sorts too. The practical effect is probably minimal,
though, as there is no reason to expect the CMVP won't eventually
approve the third submission.  That validation has a lot of company in
limbo status, too.

That's short term. There are implications for the long term too.

Note that the five year expiration will for all practical purposes
impose an upper limit on the usable lifespan of any current or future
open source based validations (such as #1051, #1747, etc.). That is
because those collaborative validations are only possible with support
from multiple separate sponsors (several dozen so far for the
#1747/#2398/#2473 module). That collaborative support results in many
platforms ("OE"s) for the one shared validation(s); over 120 platforms
for the latest module. That collaborative support makes these
validations economically feasible (barely...) and also makes the
collaborative validations valuable to a very wide range of end users.
However, the concentration of so many platforms for one validation makes
that validation(s) very vulnerable to forced changes (as will be
required to avoid the five year termination). Any forced change that
requires retesting of all the platforms is economically infeasible (I
estimate retesting of the 120+ platforms for the #1747+ validation(s)
would cost over $800K even if we could spare the time and manpower,
which we can't). Note such a forced change impact has effectively
happened already, in 2015[1], with a financially ruinous outcome for the
OpenSSL FIPS business.

What vendors can do, and are doing, is obtaining separate "clone"
("Alternative Scenario 1A/1B") or "private label" ("5SUB") validations
based on the OpenSSL FIPS module. That works well for those specific
vendors, as long as they have an open source based module to copy from,
but those copycat validations don't do the rest of the OpenSSL user
community any good and don't contribute to the support of the open
source based validations. Without sharing costs among many sponsors the
open source validations aren't possible.

So the collaborative open source based FIPS validation model that
brought us five successive OpenSSL FIPS modules, culminating in the
#1747/#2398/#2473 validation, is dead[2]. If there's any viable
opportunity to pursue a new validation I haven't seen it yet.

-Steve M.

[1] Tediously documented in the "hostage/ransom/aftermath" trilogy at
http://openssl.com/fips/

[2] See https://openssl.org/blog/blog/2015/09/29/fips/

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