On 7/19/06, Richard Salz <[EMAIL PROTECTED]> wrote:
> 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.
So anything that uses LD_PRELOAD is suspect, such as ElectricFence? My basic understanding is that all cryptographic operations (generating entropy, and actually shuffling of bits around in memory, for example with the bignum functions) must be performed within the security boundary -- and that the library APIs must not accept an unencrypted private key, and must not export an unencrypted private key. Since using the same malloc() and calloc() implementations are extremely important for application compatibility [especially on Windows as a DLL], those functions have to be overrideable to use whatever implementation the host program has... even if it differs from the OS-specific one.
> 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!
I am not involved with the validation effort in any way, so I do not have any hard data at all. However, I can hypothesize, and so I shall: There are likely architectures where an alternative BN implementation may be more efficient -- and there are definitely architectures where the current BN implementation will not run at all. In an attempt to provide as wide-spread of compatibility as possible (which was the main reason for validating the source and not mere binary modules), someone likely recognized this and felt that it would be a better idea if they were made modular. After more serious reflection (and input from the open community, since the CMVP does not discuss validation with people outside of the company which submitted the validation request until the validation passes), they most likely recognized the sub-optimal nature of that decision, and decided to suspend the validation.
As for the DES self-test, it tested API's which aren't used by the rest of the module, right?
As long as the validation query/response uses the externally-available APIs, and the code path during self-test goes through the same internal implementation, it would appear to be fine. If it doesn't, though, there's a problem.
> Well, you're waxing poetic here and I think you're being a little harsh. Only a little? :)
If the CMVP and NIST both are satisfied, the certificate will be reissued. Current implementations of OpenSSL-fips-1.0 are, notably, still validated unless it is truly revoked by the NIST. (Clerical errors notwithstanding.)
> The CMVP is doing the right thing Here we agree.
...I just wish that it were more transparent so that any further disasters could be foreseen and averted. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
