How important is FIPS 140-2 Level 1 cert?

[Peter Gutmann]

"Leichter, Jerry" <leichter_jerrold at emc.com> writes:
>| From: [Name Withheld]
>| Actually you cant even guarantee that because the FIPS 140 requirements
>| for the ANSI X9.17/X9.31 PRNG include a pile of oddball things that made
>| sense for the original X9.17 use (where it was assumed the only source
>| of entropy was a DES3 key embedded in secure hardware) but are severe
>| restrictions on current implementations. As a result a FIPS 140-
>| certified key generator will be worse than a well-designed non-FIPS-140
>| one because the FIPS requirements prevent you from doing several things
>| that would improve the functioning like injecting extra entropy into the
>| generator besides the DES3 key.
>I think this was changed as FIPS 140 evolved.  Several things about the
>random number generator evolved.  For example, in earlier versions, you had
>to run some tests on your generator at every startup.  That disappeared by
>FIPS 140-2.

That was because for a good RNG the only thing you'd ever get are false
positives, so it acted as a "make your generator fail randomly" test.

>(It makes sense for a hardware generator, but never did for software.)

There are already a pile of huge mental leaps you have to make to apply some
of the more hardware-oriented bits of FIPS 140 to software implementations, if
you read Microsoft's CryptoAPI FIPS docs you'll see some examples of these in
there.  For example the physical module boundary is the case of the PC that
Windows is running on, the role-based access control covers one single user,
whoever's using the PC at the moment, and so on - it's compliance by creating
paperwork rather than by engineering.  (I'm not trying to bash Microsoft here,
other vendors have to resort to the same thing, see e.g. the Crypto++ docs for
another public example of this).  The problem here is that FIPS 140 was
designed for military-security-model crypto hardware, has been stretched to
cover embedded device crypto, and has been seriously over-stretched to try and
cover software crypto (that is, instead of creating a distinct profile to
cover software implementations, the hardware implementation was taken into
places it was never meant to go).  The only way to reconcile the two is
through increasingly tortuous interpretations of various hardware-derived
requirements that don't really work for software.

>You're definitely free to set the starting state using any source of entropy
>you like. I *think* you can add extra entropy along the way; though even if
>this were not allowed, you could probably declare that you were restarting.

Depends entirely on who's doing the eval.  For example if you read the OpenSSL
FIPS docs (http://www.openssl.org/docs/fips/) they have an entire appendix
dedicated to a discussion of the absence of fork protection, which they
weren't allowed to add:

  The fact that this 'fork protection' is absent in the FIPS object module
  PRNG concerns many in the OpenSSL developer and user community, and will be
  the primary obstacle to making the fips configuration option a default.

In addition I've heard of evaluations where the generator is required to use a
monotonically increasing counter (clock value) as the seed, so you can't just
use the PRNG as a postprocessor for an entropy polling mechanism.  Then again
I know of some that have used it as exactly that without any problems.

(Maybe we could come up with a cross-reference of who will allow what, and
then people could choose the most sensible evaluator to submit things to).

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com