| 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. 
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.  (It makes sense for a hardware generator,
but never did for software.)

I don't have the actual text handy now, but to the best of my
recollection, there are now two approved PRNG's you can use, and the
way the text is written, what's mainly important is that you run the
internal state through the PRNG before exporting it.  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.
(Of course, this might allow the silly implementation that restarts
with state 0 on every call.  There's enough leaway in the wording of
the standard to allow a lab to toss out such a thing.)

|                                 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.
This could happen, but probably not because of a disagreement between
the labs as such:  The interpretation of the standard changes over time.
In fact, it's the interpretations - which only insiders really get to
learn about - that really define what the thing means; the written
standard leaves way too much open, most especially for software.  (It's
reasonably clear what it means to isolate hardware - though beyond that
there are some pretty specific discussions of potting technology and
such - but isolation for software?  That whole area has been defined
by interpretation.)

For what it's worth, I've been involved in (parts of, never worked
through the whole process) both FIPS 140 and Common Criteria
validations.  The latter strike me as fairly vacuous:  Shoot your
arrow (write your code), paint circles around it (define your protection
profile), declare you shot a bull's eye (certified!).  FIPS 140 *can*
have some real teeth, but it can also be gamed - again, especially
for software.  All the real meat is in the definition of the envelope.
I can declare I have a FIPS 140 certification for my AES implementation -
and then use a completely separate, insecure implementation, just so
long as I use it for "data scrambling" instead of "encryption".  A good
lab will call you if you play too many games, but ultimately labs are
paid to complete certifications, not to block them.  So it's caveat
emptor:  The full certification report is available for the customer's
review.  If you're concerned, get a copy and read it.  If the vendor
was gaming the system, that will show.  If he made a really serious
effort, that will show, too.
                                                        -- Jerry

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

Reply via email to