Re: FIPS and new releases of openssl - Openssl
This is a discussion on Re: FIPS and new releases of openssl - Openssl ; Roger No-Spam wrote:
> Hello,
>
> In appendix B of the openssl FIPS security policy it is stated that
> the module must be built with a particular tar file
> (openssl-fips-1.1.2.tar.gz) and a hmac hash value for the ...
-
Re: FIPS and new releases of openssl
Roger No-Spam wrote:
> Hello,
>
> In appendix B of the openssl FIPS security policy it is stated that
> the module must be built with a particular tar file
> (openssl-fips-1.1.2.tar.gz) and a hmac hash value for the tar file is
> specified. Furthermore it is stated that there shall be no
> additions, deletions, or alterations of the set of files in the tar
> file as used during module build.
>
> The way I read this is that if you modify for instance the ASN.1 or
> SSL code (in order to fix a bug), then the FIPS validation is
> canceled. This does not make sense to me. Why can't higher level code
> be bug fixed without FIPS validation being canceled?
FIPS 140-2 is as much ideology as technical analysis. It has the notion
of a "cryptographic module boundary" which I found surprisingly
non-intuitive at my first introduction to FIPS 140-2. Everything within
this boundary is sacrosanct and cannot be changed in any way, either
functionally or or cosmetically, not even to correct a serious flaw. So
if your module is a hardware device you can't change the placement of
components on the circuit board, even if the result is electronically
equivalent. If your module is software you cannot change a single bit of
machine code or data, regardless of the functional result (or lack thereof).
-Steve M.
--
Steve Marquess
Open Source Software Institute
marquess@oss-institute.org
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org
-
Re: FIPS and new releases of openssl
Some of the comments on FIPS 140-2 were not really fair. The points
in the standard that have caused me problems stem from the fact that
it was written as a hardware standard, and subsequently interpreted
for software. So some of the concepts are a little baroque and
unnatural. The FIPS guys, earlier this year, were wondering about
whether to break from the tradition of a single standard for hw and
sw, or to split them apart, for 140-3. I have not followed it over
the last few months.
It's not surprising that if you change anything, even something
trivial, inside your library or hardware box, that you lose your
validation status. FIPS 140 is intended to help customers buy a
crypto module and know that it works properly, without their being
crypto experts or electronics experts and doing their own analysis.
Clearly the validation must be voided if the vendor or anyone changes
the internals without re-validation.
Mike
