On Oct 13, 2013, at 1:04 PM, Ray Dillinger wrote:
>>> This is despite meeting (for some inscrutable definition of "meeting")
>>> FIPS 140-2 Level 2 and Common Criteria standards. These standards
>>> require steps that were clearly not done here. Yet, validation
>>> certificates were issued.
>
>> This is a misunderstanding of the CC certification and FIPS validation
>> processes:
>
>> the certificates were issued *under the condition* that the software/system
>> built on it uses/implements the RNG tests mandated. The software didn't,
>> invalidating the results of the certifications.
>
> Either way, it boils down to "tests were supposed to be done or conditions
> were supposed to be met, and producing the darn cards with those
> certifications
> asserted amounts to stating outright that they were, and yet they were not."
>
> All you're saying here is that the certifying agencies are not the ones
> stating outright that the tests were done.
How could they? The certification has to stop at some point; it can't trace
the systems all the way to end users. What was certified as a box that would
work a certain way given certain conditions. The box was used in a different
way. Why is it surprising that the certification was useless? Let's consider
a simple encryption box: Key goes in top, cleartext goes in left; ciphertext
comes out right. There's an implicit assumption that you don't simply discard
the ciphertext and send the plaintext on to the next subsystem in line. No
certification can possibly check that; or that, say, you don't post all your
keys on your website immediately after generating them.
> I can accept that, but it does
> not change the situation or result, except perhaps in terms of the placement
> of blame. I *still* hope they bill the people responsible for doing the tests
> on the first generation of cards for the cost of their replacement.
That depends on what they were supposed to test, and whether they did test that
correctly. A FIPS/Common Criteria Certification is handed a "box" implementing
the protocol and a whole bunch of paperwork describing how it's designed, how
it works internally, and how it's intended to be used. If it passes, what
passes it the exact design certified, used as described. There are way too
many possible system built out of certified modules for it to be reasonable to
expect the certification to encompass them all.
I will remark that, having been involved in one certification effort, I think
they offer little, especially for software - they get at some reasonable issues
for hardware designs. Still, we don't currently have much of anything better.
Hundreds of eyeballs may have been on the Linux code, but we still ended up
fielding a system with a completely crippled RNG and not noticing for months.
Still, if you expect the impossible from a process, you make any improvement
impossible. Formal verification, where possible, can be very powerful - but it
will also have to focus on some well-defined subsystem, and all the effort will
be "wasted" if the subsystem is used in a way that doesn't meet the necessary
constraints.
-- Jerry
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
