Flaws in OpenSSL FIPS Object Module
leichter_jerrold at emc.com
Tue Dec 11 16:00:42 EST 2007
| > It is, of course, the height of irony that the bug was introduced in
| > the very process, and for the very purpose, of attaining FIPS
| > compliance!
| But also to be expected, because the feature in question is
| "unnatural": the software needs a testable PRNG to pass the compliance
| tests, and this means adding code to the PRNG to make it more
| predictable under test conditions.
Agreed. In fact, this fits with an observation I've made in many
contexts in the past: Any time you introduce a new mode of operation,
you are potentially introducing a new failure mode corresponding to
it as well. Thus, bulkhead doors on sidewalks are unlikely to open
under you because the only mode of operation they try to support has
the doors opening upward. I would be very leary of stepping on such
a door if it could *ever* be opened downward.
| As the tests only test the predictable PRNG, it is easy to not notice
| failure to properly re-seed the non-test PRNG. One can't easily test
| failure to operate correctly under non-test conditions. And the
| additional complexity of the test harness makes such failure more
| The interaction of the test harness with the software under study
| needs close scrutiny (thorough and likely multiple independent code
There's a famous story - perhaps apocryphal - from the time IBM
introduced some of the first disk packs. They did great for a while,
but then started experiencing head crashes at a rate much higher than
had ever been seen in the development labs. The labs, of course,
suspected production problems - but packs they brought in worked just
as well as the ones they'd worked with earlier.
Finally, someone sitting there, staring at one of the test packs and
at a crashed disk from a customer had a moment of insight. There was
one difference between the two packs: The labs pulled samples
directly off the production line. Customers got packs that had gone
through QA. The last thing QA did was put a "Passed" sticker on the
top disk of the pack.
So ... take a pack with a sticker and spin it up. This puts G forces
on the sticker. The glue under the sticker slowly begins to migrate.
Eventually, some of it goes flying off into the enclosure. If it
gets under a head ... crash.
| Similar bugs are just as likely in closed-source software and are less
| likely to be discovered.
Actually, now that this failure mode has been demonstrated, it would
be a good idea to test for it. It's harder to do with just binaries,
but possible - look at the recent analyses of the randomization in
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography