[Cryptography] "Is FIPS 140-2 Actively harmful to software?"

John Kelsey crypto.jmk at gmail.com
Mon Jun 23 19:44:44 EDT 2014


> On Jun 20, 2014, at 3:05 PM, Theodore Ts'o <tytso at mit.edu> wrote:

...
> When you look examples such as the Taiwan's "Citizen Digital
> Certificate" which used FIPS certified smartcards, but which *still*
> had a crap random number generator, and Apple's "do not modifiy a
> single line of this file, not even a comment or else we will need to
> pay hundreds of thousands of dollars of certification fees", those are
> two strong suggestions that in fact, FIPS may be worse than nothing.
> The first showed that it FIPS certification did not have the benefits
> you would think, and the second shows active harm done by FIPS
> certification.

The first case looks like a genuine failure somewhere (or several somewheres) in the process.  But in the second case, I think you're looking at an inevitable consequence of validation--you can only validate what you see.  Let's imagine that there's some wonderful new open source crypto library, and you get a team of cryptographers and programmers to audit it as with the code audit of TrueCrypt that was going on, and they put out a statement that they checked it and it looks good.  

That audit is only meaningful until the developers start changing the code.  A code audit of the current version of the library doesn't give anyone much assurance (or shouldn't) about later versions of the library.  If you want the assurance of the audit, you can't change the code!  I don't really see any way around that.  (Go ask current users of Skype about that.)  

Similarly, if you have some validation process that just verifies that your crypto (hardware or software) really implements the algorithms it claims to implement, that validation isn't going to mean anything if you change your algorithms' implementations.  I don't see any way around this. 

The ideal situation w.r.t. a software validation would include a digital signature on the source code, right?  And then any change to the source code, or the part covered by the signature/audit, would automatically invalidate it.  You could imagine some ways to make extending the validation to include some changes more economical, and for all I know, maybe the FIPS labs do that.  But you've still got this problem:  If I can alter my code after it's been audited, I can add security-relevant bugs.  If that previous audit or validation or whatever meant anything, once I start changing my code, it doesn't mean much anymore.  

> Cheers,
> 
>                        - Ted

--John


More information about the cryptography mailing list