Re: Flaws in OpenSSL FIPS Object Module
On Tue, Dec 11, 2007 at 04:00:42PM -0500, Leichter, Jerry wrote: | 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. In fact, I was in the middle of a FIPS-140 certification at level 2 a number of years ago when the Known Answer Test for the X9.17 block cipher based PRNG was introduced. One unanticipated side effect of this test was to make it impossible to actually use a clock or free running counter as the counter in the PRNG, since the KAT expected the simplistic increment counter by 1 every time a block is extracted behavior chosen by most implementers. Of course, that mode is _less_ secure (because the internal state is more predictable) than the other, but given the choice between validate PRNG using special mode, run it using normal mode or validate PRNG using special mode, run it using special mode I know I'd pretty much always take the latter. In fact, the test lab we were using told us they were quite skeptical about the former as well. Fortunately, the requirement for the PRNG KAT was delayed long enough to let us get our code out the door without having to actually choose either of the unpalatble ways. But it does highlight a certain tension in the process: they want to know that algorithms have predictable (correct) results, but RNGs are supposed to have unpredicatable (correct) results. So any PRNG that is testable as part of the certification process pretty much _has to_ have two modes, and bugs like this may be more likely to occur in normal operation. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Flaws in OpenSSL FIPS Object Module
| 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 | likely. | | The interaction of the test harness with the software under study | needs close scrutiny (thorough and likely multiple independent code | reviews). 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 Vista ASLR. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Flaws in OpenSSL FIPS Object Module
On Mon, 10 Dec 2007 11:27:10 -0500 Vin McLellan [EMAIL PROTECTED] wrote: What does it say about the integrity of the FIPS program, and its CMTL evaluation process, when it is left to competitors to point out non-compliance of evaluated products -- proprietary or open source -- to basic architectural requirements of the standard? Integrity or ability? We all know that finding problems in code or architecture is *very* hard. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Flaws in OpenSSL FIPS Object Module
Vin McLellan wrote: What does it say about the integrity of the FIPS program, and its CMTL evaluation process, when it is left to competitors to point out non-compliance of evaluated products -- proprietary or open source -- to basic architectural requirements of the standard? Enter Reality 2.0. Yesterday, security was based on authority -- on some particular agency or expert. Today, security is /also/ based on anyone else that can point out non-compliance, and solutions. The integrity of the FIPS program, and any other evaluation process, can only increase when [x] are also able (entirely on their own and not by a mandate) to point out non-compliance of evaluated products -- proprietary or open source -- to basic architectural requirements of the standard. Here [x] = competitors, attackers, outside experts, anyone in general. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Flaws in OpenSSL FIPS Object Module
| What does it say about the integrity of the FIPS program, and its CMTL | evaluation process, when it is left to competitors to point out | non-compliance of evaluated products -- proprietary or open source -- | to basic architectural requirements of the standard? I was going to ask the same question. My answer: This proves yet again how far we are from a servicable ability to produce secure software. Software that's been through the FIPS process has been vetted to the limits of our current abilities under the constraints of being even vaguely commercially viable. OpenSSL is open source software that's been around for a long time, examined by many, many people. It had a very rough journey through the FIPS process, so was presumably checked even more than software that just breezes through. Even so ... it had a security bug. It's hard to suggest something that could have been done differently to guarantee that this couldn't happen. Anyone who might argue - as I'm sure they will - that this proves you should use commercial software rather than OSS if you need security is speaking nonsense - that's not at all what this incident is about. 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! -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
