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 
                                                        -- Jerry

The cryptography mailing list

Reply via email to