Fwd: questions on fips provider

[Ishani]

---------- Forwarded message ---------
From: Ishani <18r01a05n6 at gmail.com>
Date: Mon, 3 Jul, 2023, 12:59 pm
Subject: Re: questions on fips provider
To: <pauli at openssl.org>


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 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 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/b6af88c8/attachment-0001.htm>