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 firstname.lastname@example.org http://www.metzdowd.com/mailman/listinfo/cryptography