> You're probably referring to the critique that Tim Hudson of RSA SI has > been circulating.
No, I didn't know Tim has been circulating a critique. > As for ?breaks in security?, for level 1 validations the CMVP recognizes > that there is no effective defense against malicious subversion of > software. An attacker with write access to a validated module can disable > the integrity checks, corrupt keys, modify algorithms, etc. FIPS 140-2 > level 1 does not require defenses against malicious attack, other than the > initial integrity test and configuration of the host operating system in > ?single user mode?. But providing an alternative implementation of a routine outside of the security boundary a priori cannot be malicious, and therefore this "attack" is entirely legitimate. Further, it needn't be the application itself that provide an alternate implementation, but rather a separate library that the application uses. If an application developer needs to ensure that every non-system library doesn't provide alternate implementations of certain functions, then the security policy needs to say that. > Initially our guidance was that the BN library, which was not contained in > the crypt module boundary, was an acceptable ?non cryptographic? > reference. Who gave that guidance, and to whom? I'd like to hear the rationale. The RSA key operations are implemented via BN calls! As for the DES self-test, it tested API's which aren't used by the rest of the module, right? > Well, you're waxing poetic here and I think you're being a little harsh. Only a little? :) > The CMVP is doing the right thing Here we agree. > BTW the correct term is ?validation?, not ?certification?. Yeah, I keep forgetting that. And I've been involved with FIPS and Common Criteria for many years. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
