On 04/08/2016 17:53, Thomas Francis, Jr. wrote:
...
I really should point out three things, though:
1) FIPS 140 compliance (from any software package) is always less secure than
non-FIPS 140 compliant packages. By its nature, the validation process places
software several months to years out of date, and no changes are allowed, even
to address severe security problems. There are known security problems in at
least some of the OpenSSL FIPS modules.
2) FIPS 140 compliance is _not_ about security. It’s about proving that
specific algorithms are in use, for purposes of government auditing. Nothing
in the compliance tests actually prove that, either. The algorithms must
simply be able to produce the correct output for well-known inputs (that
includes several runtime tests that also only prove it gives the right output
for well-known inputs), and there must exist some sort of “proof” that the
module has not been modified from the tested form. There’s nothing in there to
prevent FIPS 140 validation of a module that stores all your keys and sends
them to someone else, and there’s nothing in there to prevent FIPS 140
validation of a module that contains algorithms that only do the right thing
for those well-known inputs. There are even approved algorithms that have been
shown to be insecure, even when the software implements the algorithm correctly
(see Dual EC DRBG).
3) Unless you’re required by regulation to have FIPS 140 compliance, you should
avoid it like the plague it is. It’s less secure, and you’ll never be able to
update your software in a timely manner (even if there were no security
problems, which is unlikely). Given that you reference COTS instead of GOTS, I
suspect you’re not working for a government agency that is required to comply
with FIPS 140.
At least one public non-gov CA has made the mistake of putting
FIPS-140-2 compliance into one of their CP/CPS documents for
how non-gov certificate holders should store their private key.
Hopefully, this is an outlier, but it shows that FIPS 140-2
requirements sometimes sneak outside the USGOV context.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
