FIPS 140-2 Validation Revoked
marq...@oss-institute.org
of the OpenSSL FIPS object module has been revoked:=20
http://www.gcn.com/online/vol1_no1/41371-1.html.
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 validation has been under seige by a few detractors from the
beginning. We thought we had successfully addressed all the known
challenges to date, including the most recent one that resulted in the
relinking of the FIPS object module
(http://oss-institute.org/index.php?option=3Dcontent&task=3Dview&id=3D163=
).
John and I are already being asked what happens next. At this point we
don't know, but we haven't necessarily given up. As we learn more I'll
pass on our findings here.
-Steve M.
--=20
Steve Marquess
Veridical Systems, Inc.
marq...@veridicalsystems.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List opens...@openssl.org
Automated List Manager majo...@openssl.org
Richard Levitte - VMS Whacker
marquess> John and I are already being asked what happens next. At
marquess> this point we don't know, but we haven't necessarily given
marquess> up. As we learn more I'll pass on our findings here.
Having been part of the work and discussions for and about
FIPSification and having personally felt thoroughly discouraged, I'm
incredibly impressed by your courage, tenacity and power in this
process. All power to you, and maybe I'll find the courage to get my
head into it again (I've other things to resolve first, though).
Cheers,
Richard
-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte ric...@levitte.org
http://richard.levitte.org/
"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
-- C.S. Lewis
marq...@oss-institute.org
> Well, the first news report is out stating that the FIPS 140-2 validati=
on
> of the OpenSSL FIPS object module has been revoked:
> http://www.gcn.com/online/vol1_no1/41371-1.html.
>
> ...
>
> John and I are already being asked what happens next. At this point we
> don't know, but we haven't necessarily given up. As we learn more I'll
> pass on our findings here.
Just received a call from the CMVP test lab saying that the CMVP has
informed them that the validation is *not* revoked, just suspended as
before pending review of the relinked version (1.1), and that the earlier
notification of revocation was delivered in error.
So, back to waiting on the review of the new deliverable which should onl=
y
take a fews days (though I've certainly underestimated these time frames
before :-)
-Steve M.
--
Steve Marquess
Veridical Systems, Inc.
marq...@veridicalsystems.com
Richard Salz
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.
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!
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 API's. (OpenSSL includes multiple DES/3DES
implementations.)
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-ccertified OpenSSL that it is not safe
to do so.
/r$
marq...@oss-institute.org
> 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 =96 sour=
ce
code distribution, the concept of the monolithic object module.=20
Fortunately a simple mitigation was possible, and agreed to, namely movin=
g
questionable object code into fipscanister.o.
At that time we were told that the validation would be =93suspended=94 pe=
nding
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.=20
I've since seen a statement from the CMVP that the revocation announcemen=
t
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 c=
ode
> 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 a=
nd
> when asked for random numbers always returned the same value. I know th=
is
> 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 mo=
re)
> trusted the vendor; had they performed the most basic due diligence --
> compile the program! -- they would have seen that the code should not h=
ave
> 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) no=
r
carefully examined the resulting object code (they performed an
excruciating analysis of the object code and are well versed in the use o=
f
nm, objdump, and the like).
As for =93breaks in security=94, for level 1 validations the CMVP recogni=
zes
that there is no effective defense against malicious subversion of
software. An attacker with write access to a validated module can disabl=
e
the integrity checks, corrupt keys, modify algorithms, etc. FIPS 140-2
level 1 does not require defenses against malicious attack, other than th=
e
initial integrity test and configuration of the host operating system in
=93single user mode=94.
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 (=93private keys=94) -- as wit=
h
mallow(), for example. In addition, the CMVP guidance also stated that
external calls to other standard application code is acceptable as long a=
s
such references were not =93cryptographic in nature=94.
Initially our guidance was that the BN library, which was not contained i=
n
the crypt module boundary, was an acceptable =93non cryptographic=94
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 =96 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 on=
e
> used by the public Ape's. (OpenSSL includes multiple DES/3DES
> implementations.)
Tim misread the DES self-test implementation =96 look at the fourth argum=
ent
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 widespr=
ead
> 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 saf=
e
> to do so.
Well, you're waxing poetic here and I think you're being a little harsh.=20
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 =93validation=94, not =93certification=94. Also,=
OpenSSL
was not validated, the validated product is the OpenSSL FIPS Object
Module, a separate software component designed for use with OpenSSL. Bot=
h
common slips; it took me a year to break that habit :-)
-Steve M.
Richard Salz
> 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=20
disable
> the integrity checks, corrupt keys, modify algorithms, etc. FIPS 140-2
> level 1 does not require defenses against malicious attack, other than=20
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=20
security boundary a priori cannot be malicious, and therefore this=20
"attack" is entirely legitimate. Further, it needn't be the application=20
itself that provide an alternate implementation, but rather a separate=20
library that the application uses. If an application developer needs to=20
ensure that every non-system library doesn't provide alternate=20
implementations of certain functions, then the security policy needs to=20
say that.
=20
> Initially our guidance was that the BN library, which was not contained=20
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? :)
=20
> 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.
Kyle Hamilton
>
> > 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
> > the integrity checks, corrupt keys, modify algorithms, etc. FIPS 140-2
> > level 1 does not require defenses against malicious attack, other than
> > 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
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
Richard Salz
Well, it shouldn't be; that's the point. And the problem with the current
code.
> 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.
There are limits and trade-offs. Classic OS/library features don't have
to be within the secure boundary. But to say that something like the big
number package, or the DES implementation used by the exported API needn't
be?
> 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.
Nope, you can't do that. What's the point of validation of the real part
of the implementation (e.g., RSA without a bignumber package??) isn't part
of the validated code?
> 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.
It is unfortunate that the FIPS module was developed in such a closed
source manner. There are many people who would have caught these flaws
much earlier in the process.
> 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.
And that is exactly what is the problem with the DES self-test. I was
wrong when I said that decryption isn't tested -- I took another look at
the code and misread it. But still, the wrong routine is what's tested.
> 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.)
I assume you mean the validation lab and CMVP/NIST...
As for whether or not it's still validated, you have to read
http://csrc.nist.gov/cryptval/140-1/1401val.htm . As I interepret it, if
you downloaded the code prior to the date of suspension, you can still use
it. If you downloaded it /after/ the suspension, you cannot use it. Is
there any other way to view 'procurement' for OSS than download?
> ...I just wish that it were more transparent so that any further
> disasters could be foreseen and averted.
Yes. This is primarily what I was alluding to when I said changes in
process.
/r$