On 27/02/2019 22:18, Richard Levitte wrote:
On Wed, 27 Feb 2019 21:55:29 +0100,
Jakob Bohm via openssl-users wrote:
On 27/02/2019 20:59, Salz, Rich via openssl-users wrote:
If you change a single line of code or do not build it EXACTLY as documented, you cannot claim to use the OpenSSL validation.
I believe the context here is one I also mentioned in my comment on
the 3.0 draft spec:
- OpenSSL FIPS Module provides FIPS validated software implementations of
all/most of the permitted algorithms.
- Engine provides FIPS validated (hardware?) implementations of one or
more implementations, under a separate FIPS validation, perhaps done
at the hardware level.
- FIPS-capable OpenSSL (outside the FIPS boundary) is somehow made to use
both FIPS validated modules depending on various conditions (such as
algorithm availability). FIPS-capable OpenSSL can be changed without
breaking the FIPS validation of the modules.
- Overall application claims FIPS compliance as all crypto is done by
FIPS validated modules.
Side note: "FIPS-capable OpenSSL" isn't quite right. Basically, if
libcrypto is capable of loading a dynamically loadable module, it's
"FIPS-capable", since it can load the FIPS provider module.
I always understood "FIPS-capable OpenSSL" to refer specifically to an
OpenSSL compiled with the options to incorporate the FIPS canister
module, not just any OpenSSL build that might be used in FIPS compliant
applications (as that would be any OpenSSL at all).
I see no reason why libcrypto should be able to load two
FIPS-validated modules (*) and use them both, all depending on what
algorithms and properties are desired (apart from the "fips"
property). However, I've come to understand that those two modules
must not be made to cooperate, i.e. for a signing operation using
sha256WithRSAEncryption, it's not permitted for one module to do the
sha256 part and the other module to do the RSA calculations.
Cheers,
Richard
-----
(*) an engine module is also a module... all that actually makes it
an OpenSSL engine is two entry points, "bind_engine" and "v_check".
How does this understanding work for other applications that use a
FIPS-validated smart card (cryptographic boundary for validation is
the physical card boundary) to sign messages? Are such applications
required to pass every message (mega)byte through the smart card
serial interface so the low speed smart card chip can do the hashing?
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
