[openssl-users] Validation status of openssl-fips-2.0.11?

[Kyle Hamilton]

On 2/12/2016 2:03 PM, Steve Marquess wrote:
> On 02/12/2016 04:26 PM, Kyle Hamilton wrote:
>> I'm not seeing anything about openssl-fips-2.0.11 in
>> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747
>> , so I'm not quite certain what its validation/certificate status is? 
> Ok, this is complex, insanely so.
>
> [concise explanation of insanely complex and incredibly messy situation trimmed]
>
> Yeah, it's a mess.

Thank you for explaining it.  It feels to me like they're intentionally
making it as difficult as possible for OpenSSL to maintain its validations.

#2398 has the correct version that I'm looking for, so that's what I'm
documenting.  However, it also suggests that there's a 2.0.12 that was
validated as of 02/08/2016?  This is not yet distributed on the website.

>> Also, is a new Security Policy in the works integrating the new HMAC
>> digests for the new versions of -fips and -fips-ecp?
> I don't understand this question.

https://openssl.org/docs/fips/SecurityPolicy-2.0.pdf points to
SecurityPolicy-2.0.9.pdf; this is the version that I got, which did not
have the new HMAC values for openssl-fips-ecp-2.0.11.tar.gz.  I was
wondering if there was a SecurityPolicy-2.0.11.pdf.  It appears there
is, but the "official" link to 140sp2398.pdf points to a
SecurityPolicy-2.0.12.pdf.  So, I can't quite manage to figure out if
I'm getting my security policy through a secure path (please see the end
of this email for more on what I mean, and why I say this).

>> (Also, would the mandatory HMAC calculation of the original tarball be
>> okay if it were done using a FIPS-validated version of Mozilla's NSS?)
> You wouldn't believe how deep that rabbit hole goes. See section 6.6 of
> the OpenSSL FIPS user guide
> (https://openssl.org/docs/fips/UserGuide-2.0.pdf). The answer to that
> question is why we're still snail-mailing CDs (see
> http://openssl.com/fips/verify.html).

My understanding of this requirement is:  A secure path can only be
established via mail/courier, or via some series of FIPS-validated
cryptographic modules.

As a result, I cannot use any non-validated openssl to bootstrap to a
validated openssl-fips, because the chain of FIPS-validated
cryptographic verification must not be broken.  If I have another
FIPS-validated module which is validated for SHA1-HMAC, I can use it in
accordance with its security policy to perform the HMAC verification. 
If I already have a FIPS-validated openssl, I can use it.  Otherwise, I
must obtain the CD from OpenSSL Foundation (most likely via registered
mail -- not even certified mail, but registered mail).

There do exist other FIPS-validated modules, like the FIPS-validated
NSS: I've already set all of the cryptography in my Firefox installation
to be through the NSS FIPS module (using cipher
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2 --
compliant with the FIPS TLS implementation guidance).  Since I'm using a
FIPS-validated NSS to perform the cryptography to download from
https://openssl.org/source/openssl-fips-ecp-2.0.11.tar.gz, would that
pass the "secure path" challenge, or would I still need to write
something to perform the HMAC test specified in Appendix B of the
Security Policy using the NSS FIPS module?

I suspect the answer depends on whether openssl.org's TLS stack is using
OpenSSL in FIPS mode.  Because I do not know if it is (and the site
itself does not mention it), I think I should assume that the TLS stack
of openssl.org does NOT operate in FIPS mode, and thus I shouldn't rely
on it as being part of the necessary trusted path.  Because of this, I
think I should assume that HMAC verification in accordance with Appendix
B is still compelled.

I hope that this insight might be helpful, though.

-Kyle H