questions on fips provider

[pauli at openssl.org]

No, the legacy provider doesn't do any integrity checks on load. There 
is no need.

Likewise, the FIPS integrity check is _not_ attempting to detect 
tampering, it is designed to detect accident bit flipping.
Detecting deliberate tampering is far more involved to the point of 
being virtually impossible.


Paul Dale

On 3/7/2023 5:29 pm, Ishani wrote:
> Hi Paul,
>
> Yes it does do an integrity check on load.  This was the main reason 
> to limit the FIPS provider to being a loadable module.  The approach 
> taken in the 1.0.2 FOM wasn't viable with the re-architecture.
>
>  I assume these checks will be done even if we programmatically load fips.
> **Do we have similar checks for legacy provider as well (to make sure 
> legacy.so/legacy.dll <http://legacy.so/legacy.dll> loaded is the right 
> one and not something tampered by some body)?
>
> On Fri, 30 Jun 2023 at 12:45, <pauli at openssl.org> wrote:
>
>     Answers below....
>
>>     1) Is there a way to static link FIPS? I see at many places that
>>     fips cannot be statically linked but would like to know if we
>>     have any other ways to do that.
>
>     No.  This was a design goal/limitation from the start.  Statically
>     linking the FIPS provider would have been a major source of pain. 
>     We managed it for 1.0.2 with some inspirational assembly coding
>     but that approach wouldn't have worked for 3.0.
>
>
>>     2) If it is dynamic linking then does FIPS has any integrity
>>     check to make sure fips.so/fips.dll <http://fips.so/fips.dll> is
>>     the right one? and not some thing tampered by some body(as per my
>>     findings we have some check in configuration file as mentioned in
>>     the below attached snapshot 3rd line)
>
>     Yes it does do an integrity check on load.  This was the main
>     reason to limit the FIPS provider to being a loadable module.  The
>     approach taken in the 1.0.2 FOM wasn't viable with the
>     re-architecture.
>
>
>>     3) can both legacy and fips providers be loaded and used?
>
>     Technically yes, but you'll not be FIPS compliant unless you are
>     *extremely* careful.
>     Which means talking to your FIPS labs and getting official
>     resolutions on the specifics.
>     The OpenSSL developers are ***not*** FIPS experts. Only a FIPS lab
>     can definitively answer questions like this.
>
>
>>     4) Is it possible If i have built openssl with no-module
>>     configure option (to statically link legacy provider) and also
>>     wanted to use openssl-3.0.8 built fips module here? If yes then
>>     in what way can it be done?
>
>     Honestly not sure here.  You *must* load the FIPS provider
>     dynamically to be compliant.
>     If that's possible with the no-module option, you should be okay. 
>     I suspect it isn't.  Try it and see.
>
>     If you don't get a definitive result, this means talking to your
>     FIPS labs and getting official resolutions on the specifics.
>     The OpenSSL developers are ***not*** FIPS experts. Only a FIPS lab
>     can definitively answer questions like this.
>
>
>>     5) Is it possible to load multiple providers like default, leacy
>>     and also fips programmatically using OSSL_PROVIDER_load function ?
>
>     Absolutely it is possible.  However, meeting FIPS requirements
>     afterwards could be problematic.
>     This means talking to your FIPS labs and getting official
>     resolutions on the specifics.
>     The OpenSSL developers are ***not*** FIPS experts. Only a FIPS lab
>     can definitively answer questions like this.
>
>     Having several library contexts with each having different
>     providers loaded might be a way to circumvent the strict
>     interpretation of the requirements. This means talking to your
>     FIPS labs and getting official resolutions on the specifics.
>     The OpenSSL developers are ***not*** FIPS experts. Only a FIPS lab
>     can definitively answer questions like this.
>
>
>>     6) When multiple providers like for ex:  FIPS and default
>>     provider are enabled and when an encryption function is called,
>>     then algorithm from which provider is picked(from my findings it
>>     can use any of the loaded provider implementations )? assumption
>>     that we have *not* used property query string during algorithm
>>     fetches to specify which implementation to be used.
>
>     The OpenSSL project *deliberately* makes *no guarantee* about
>     which provider is used in such cases.  It is deterministic
>     currently, but there is no guarantee that we'll not change the
>     order of resolution or making it randomly non-deterministic in any
>     future releases.  Honestly, expect that *we will* make changes to
>     the resolution order in the future.  Such a change is not
>     considered breaking and doesn't have to adhere to our stable
>     release policy.
>
>     Our best recommendation is to not mix providers in library
>     contexts.  Seek resolution from you FIPS lab.
>
>
>     Dr Paul Dale
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230703/5a965df1/attachment.htm>