----- Forwarded message from [EMAIL PROTECTED] ----- From: [EMAIL PROTECTED] Date: Wed, 19 Jul 2006 14:01:03 -0500 (CDT) To: openssl-dev@openssl.org Cc: [EMAIL PROTECTED] Subject: Re: FIPS 140-2 Validation Revoked User-Agent: SquirrelMail/1.4.6 Reply-To: openssl-dev@openssl.org
Richard Salz wrote: > I wish to make it very clear that in this message I am speaking solely as > an individual, and do not represent my employer or its views in any way at > all. > >> We don't know the full story behind this yet, and perhaps never will. As >> John Weathersby noted in the article, "This is not about technology". > > This is baloney. Hmmm, not so fast. On June 16 we submitted a revised FIPS object module (v1.1) to address the concerns about the crypto module boundary that had been discussed extensively beforehand. Frankly we agreed with the CMVP that the treatment of some external references was less careful than it should have been. During the validation process most of our collective attention was absorbed with the unique aspects of the validation source code distribution, the concept of the monolithic object module. Fortunately a simple mitigation was possible, and agreed to, namely moving questionable object code into fipscanister.o. At that time we were told that the validation would be suspended pending the review, not revoked, and the validation (#642) restored if the new submission met the agreed upon criteria of removing all external references to OpenSSL. The announcement last Friday that the validation was revoked thus came as a surprise, as did the announcement yesterday that it was un-revoked. I've since seen a statement from the CMVP that the revocation announcement was in fact a clerical error in updating the web site, a mere clerical mistake. > The "boundary" around the formerly-validated code was completely wrong -- > a simple analysis showed that code within the "FIPS container" called code > outside the container. A sample program showed how this led to trivial > breaks in security. I have seen a document that had this analysis, and > included a sample program that printed all private keys to the screen and > when asked for random numbers always returned the same value. I know this > document was given to the module authors and the validation lab. The > authors ignored this and also convinced the validation lab to ignore it. > The lab (I'm really glad they're not a subsidiary of my employer any more) > trusted the vendor; had they performed the most basic due diligence -- > compile the program! -- they would have seen that the code should not have > passed. Hell, 'nm fipscanister.o | fgrep U' would have shown it! You're probably referring to the critique that Tim Hudson of RSA SI has been circulating. We, and the CMVP, are keenly aware of those criticisms. You mistakenly assume that the validation testing lab neither compiled the software (they had to, they received the source distribution only) nor carefully examined the resulting object code (they performed an excruciating analysis of the object code and are well versed in the use of nm, objdump, and the like). 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. The module boundary issue isn't as simple as it first seems when discussing a pure software library. Any such software will necessarily contain external references to (at least) shared system libraries and system calls. There was already an established precedent that external calls to standard system libraries are allowable, even where such calls, maliciously intercepted, could expose CSPs (private keys) -- as with mallow(), for example. In addition, the CMVP guidance also stated that external calls to other standard application code is acceptable as long as such references were not cryptographic in nature. Initially our guidance was that the BN library, which was not contained in the crypt module boundary, was an acceptable non cryptographic reference. As noted above we subsequently concluded that all BN references, and in fact all OpenSSL references, should be included. That was done by changing the link step to pulling all such references into fipscanister.o ... rather a crude fix, but all the time constraints allowed. For the longer term we are planning on a clean slate follow on validation to leverage the lessons learned a tight stand-alone source tar ball, 0.9.8 support, shared library support, etc. > There were other problems as well. For example, the DES/3DES self-test did > not test encryption. Even worse, the implementation tested isn't the one > used by the public Ape's. (OpenSSL includes multiple DES/3DES > implementations.) Tim misread the DES self-test implementation look at the fourth argument to the DES_ebb_encrypt() function which is used for both encryption and decryption. FIPS 140-2 does not require that the APIs of the validated module be used directly by all applications. All these allegations were covered in detailed correspondence between myself, the OpenSSL team, and the CMVP. > Open source is not magic pixie dust that allows you to ignore basic > reality. The certified code had serious flaws that were known to the > parties involved in certification, yet they went ahead anyway. CMVP did > the right thing. Can you imagine the damage that could have been done if > either critical systems were built using that code, or if a true enemy of > the open source movement published the sample code after it had widespread > use? > > It greatly saddens me to say this, but unless there are significant > changes in the process and/or participants, I will continue to advise > anyone who wants to rely on a FIPS-certified OpenSSL that it is not safe > to do so. Well, you're waxing poetic here and I think you're being a little harsh. The CMVP is doing the right thing, performing careful analysis and allowing us to correct the one flaw they identified from the many allegations. This validation effort, some four years in the running, has been a learning experience for all of the participants, CMVP included. I give them credit for their commitment and effort in breaking new ground, when a less dedicated bureaucracy would have found excuses to punt. The understanding of the complexities in applying FIPS 140-2 to source based portable code, and the corresponding guidance from the CMVP, has changed and matured considerably since we started. BTW the correct term is validation, not certification. Also, OpenSSL was not validated, the validated product is the OpenSSL FIPS Object Module, a separate software component designed for use with OpenSSL. Both common slips; it took me a year to break that habit :-) -Steve M. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
signature.asc
Description: Digital signature