On Sun, Aug 24, 2008 at 3:39 AM, Kyle Hamilton <[EMAIL PROTECTED]> wrote: > Re https://bugzilla.mozilla.org/show_bug.cgi?id=419030 > > I appreciate that you have tried... but I must also appreciate that > you have failed. I have a major concern, and I think that if you > verified this with the CSRC or your FIPS validation lab, they would > second it. > > The FIPS validation is not applied to the source code, but rather to > the binary produced from the source code which is submitted. If you > recompile the code, the version that you get from the code is not > validated -- only the actual binary PKCS#11 module which was submitted > to the validated laboratory is validated. If you expect that CVS > saves you from that, I must point out that it is entirely possible for > a CVS repository to be edited by hand without being detectable by the > command-line tool. > > OpenSSL has the only FIPS-validated source-procurable implementation > in existence. The amount of work that went into it is amazing, and it > is only made possible by having a verifiably trusted path from an > SHA-1 hashed tarball that contains source files and a file which > contains keyed HMACs of all of the source files which are verified by > the make process, then HMACs of all of the generated object files are > generated and put into a single .o file, which is then HMAC-signed > overall. On module load and the call to FIPS_mode_set(1), the > entirety of the chained-validated binary code in the process space is > key-HMACed, and the HMAC compared with what's stored in the module > itself. If it fails, it detects that it is not validated, and goes > into the error-detected state, which prevents any cryptographic > operation from occurring with it.
I must address some myths. FIPS 140-2 Implementation Guidance Section G.5 allows a vendor and even a user to recompile or port a module and maintain the validation status: http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf There is no such thing as source code validation. The FIPS testing labs test binaries of the crypto modules. The so-called source code validation of OpenSSL is a standard binary validation plus what Implementation Guidance G.5 allows for recompilation and porting. Our recompilation of NSS follows the specs of Implementation Guidance G.5. (Any C programmer experienced with writing cross-platform software should be appalled by what Implementation Guidance G.5 allows for porting. This is why we spent the extra money and effort to have NSS validated on seven platforms.) The HMAC process you described is the software integrity test. NSS uses DSA in the software integrity test. It is a glorified checksum. Its purpose is to detect accidental file corruption, not malicious file substitution. (The attacker would just substitute the HMAC key, too. DSA-based software integrity test has the same issue.) This is why we named our signature files softokn3.chk and freebl3.chk as opposed to .dsa. Wan-Teh _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
