[marquess at oss-institute.org: Re: FIPS 140-2 Validation Revoked]

[Eugen Leitl]

----- Forwarded message from marquess at oss-institute.org -----

From: marquess at oss-institute.org
Date: Wed, 19 Jul 2006 14:01:03 -0500 (CDT)
To: openssl-dev at openssl.org
Cc: jmw at oss-institute.org
Subject: Re: FIPS 140-2 Validation Revoked
User-Agent: SquirrelMail/1.4.6
Reply-To: openssl-dev at 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 at openssl.org
Automated List Manager                           majordomo at openssl.org

----- 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20060719/328c043e/attachment.pgp>