Re: How important is FIPS 140-2 Level 1 cert?

[Thor Lancelot Simon]

On Tue, Dec 26, 2006 at 05:36:42PM +1300, Peter Gutmann wrote:
 
 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.

This (braindamaged) requirements change was brought in by the creation of
a Known Answer Test for the cipher-based RNG.  Prior to the addition of
that test, one could add additional entropy by changing the seed value at
each iteration of the generator.  But that makes it, of course, impossible
to get Known Answers that confirm that the generator actually imlements
the standard.  So suddenly the alternate form of the generator -- in my
opinion much less secure -- which uses a monotonically-increasing counter
for the seed, was the only permitted form.

I have yet to hear of anyone who has found a test lab that will certify
a generator implementation that uses the mono counter for the KAT suite
but a random seed in normal operation.  For good reason, labs are usually
very leery of algorithm implementations that come with a special test
mode.

However, you are free to change the actual key for the generator as often
as you like.  I'm not sure why OpenSSL doesn't implement fork protection
that way, for example -- or does it use the MAC-based generator instead?

Thor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: How important is FIPS 140-2 Level 1 cert?

[lists]

On 22 Dec 2006 11:43:58 -0500, Perry E. Metzger wrote:
 [I was asked to forward this anonymously. --Perry]
 
 From: [Name Withheld]
 To: cryptography@metzdowd.com
 Subject: Re: How important is FIPS 140-2 Level 1 cert?
 
 Paul Hoffman [EMAIL PROTECTED] wrote:
 
 At 11:25 AM -0500 12/21/06, Saqib Ali wrote:
 If two products have exactly same feature set, but one is FIPS 140-2
 Level 1 certified but cost twice. Would you go for it, considering the
 Level 1 is the lowest.
 
 Assuming that the two products use Internet protocols (as compared to
 proprietary protocols): no. Probably the only thing that could
 differentiate the two is if the cheaper one has a crappy random number
 generator, the more expensive one will have a good one.
 
 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. In addition since no two eval labs can
 agree on exactly what is and isnt OK here its pretty much a crap-shoot
 as to what you can get through. Ive heard stories from different vendors
 of Lab B disallowing something that had already been certified by Lab A
 in a previous pass through the FIPS process.

These statements are not entirely correct for FIPS 140-2 under current 
interpretations (to my understanding, at least).

For example,

ANSI X9.31 is not the only FIPS-approved PRNG. There are a few of them [1], 
although most of them are closely related.

You can reseed a FIPS-approved PRNG all you want, which means you could even 
effectively reduce a FIPS-approved PRNG to a whitener if you
desired. (There are some caveats here.) IIRC, yarrow takes this sort of 
approach. Also, as noted elsewhere, some of the PRNGs have explicit
mechanisms for you to feed in more entropy.

For an X9.31 PRNG, (re)seeding can include (re)keying the 2-key TDES and often 
does as implementers try to cram as much gathered entropy
into the PRNG as possible.

Also, lab interpretations of requirements can vary a bit in some of the more 
ambiguous areas, especially on the things like the stretches
made for validating software, or with novel implementations; however, overall, 
they are quite similar. I think the bigger lab variations
revolve around things like the staff on hand , which can effect, for example, 
how quickly a lab can understand a product, how effectively a
lab can interpret that understanding against the requirements, and how much 
bandwidth the lab has to just get the job done.

 In terms of its value, particularly for level 1, what itll give you is
 (1) protection from egregiously bad implementations (which a quick
 source code check will do as well) and (2) the ability to sell to US
 federal agencies. Beyond that I concur that 10 minutes of interop
 testing with the standardised protocol of your choice (e.g. TLS, S/MIME,
 IPsec) will give you more than FIPS 140 will since a run of TLS tests
 much more of the crypto than FIPS 140 does.

As to the original direction of this thread, I agree with these value adds. 
Point two is the main reason anyone pursues FIPS 140-2 at this
point, although this might change with the internationalization efforts. As to 
point one, it is worth noting that many vendors have not had
anyone review their crypto up until going through a FIPS 140-2 validation. And, 
FIPS 140-2 looks at the overall picture more than just
particular protocols, by including requirements in areas like the whole of key 
management, and authentication and authorization (noting this
applies at level 2). So, even at level 1, this can mean a fair amount of real 
problems being discovered and resolved as a result of the
process. (Of course, if you require stronger levels of third party review of a 
product, then higher levels of FIPS 140-2 validation or
perhaps other programs like NSA certifications are more what you should be 
looking at.) And, to add a third value, FIPS 140-2 validation can
function much like having letters like CISSP following one's name.

With regards to protocol interop, as part of the FIPS 140-2 process currently, 
algorithm testing is involved. Perhaps protocol testing
requirements should be included in the next revision of the standard being 
worked on at the moment [2]. I do agree this would help to
strengthen the FIPS 140 process.

(Reading this overall thread, it seems FIPS 140 is still considered some sort 
of voodoo. The FIPS 140-2 requirements are public [3], and
even the ambiguous areas have standard interpretations at this point.)

-Andrew

[1]