[openssl-users] Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)
tmraz at redhat.com
Fri Feb 15 12:58:12 UTC 2019
On Fri, 2019-02-15 at 11:23 +0000, Matt Caswell wrote:
> On 15/02/2019 03:55, Jakob Bohm via openssl-users wrote:
> > yout - but this is useful input.
> > FIPS-specific issues:
> > - The checksum of the FIPS DLL should be compiled into the FIPS-
> > capable OpenSSL library, since a checksum stored in its own file
> > on the end user system is too easily replaced by attackers. This
> > also implies that each FIPS DLL version will need its own file
> > name
> > in case different applications are linked to different libcrypto
> > versions (because they were started before an upgrade of the
> > shared
> > libcrypto or because they use their own copy of libcrypto).
> This is not an attack that we are seeking to defend against in 3.0.0.
> consider the checksum to be an integrity check to protect against
> changes to the module.
+1 to Matt. The integrity check of FIPS standard was never ment to be a
mitigation against active attacks. Its purpose always was just
protection against inadvertent HW or SW errors.
Building the checksum into a binary overly complicates things and it is
not worth the hassle as it would not protect against active attacks
either, it would just complicate them a little.
> > - If possible, the core or a libcrypto-provided FIPS-wrapper should
> > check the hash of the opensslfips-3.x.x.so DLL before running any
> > of its code (including on-load stubs), secondly, the DLL can
> > recheck itself using its internal implementation of the chosen MAC
> > algorithm, if this is required by the CMVP. This is to protect
> > the
> > application if a totally unrelated malicious file is dropped in
> > place of the DLL.
> As above - this is not an attack we are seeking to defend against.
No matter how far down the wrong road you've gone, turn back.
[You'll know whether the road is wrong if you carefully listen to your
More information about the openssl-users