Thank you all for your detailed and quick responses 😊. It has helped to understand fips in a more clear way.
one more question I have is - we opted to load providers programmatically so that we don't need to maintain the openssl.cnf file and it's path separately. But when fips provider comes into picture , from my findings it looks like fipsmodule.cnf is needed and it is to be used through openssl.cnf only(by adding .include <fipsmodule.cnf path> and a few more changes).
1. Do we have any way to load fips provider without using configuration files(openssl.cnf,fipsmodule.cnf)?
2. may be using only 1 of them but not both ?
On Fri, 30 Jun 2023 at 13:47, Matt Caswell <matt@xxxxxxxxxxx> wrote:
On 30/06/2023 08:58, Zhongyan Wang wrote:
> How to specify the path of openssl.cnf and so-called fipsmodule.cnf
> programmatically when load FIPS Provider?
You can use `OSSL_LIB_CTX_load_config` to load a specified config file.
It is recommended that you provide an absolute path to fipsmodule.cnf in
openssl.cnf. If a relative path is provided then the
OPENSSL_CONF_INCLUDE environment variable is assumed to contain a
directory which is prepended to the include path.
If OPENSSL_CONF_INCLUDE does not exist then you can add this line to
openssl.cnf to specify the include directory:
.pragma includedir:/path/to/a/directory
If the result is still relative then it is assumed to be relative to the
current working directory of the process.
Matt
>
> Our product has a build-in openssl bin and library, but doesn’t have any
> openssl configure file due to history reason.
>
> I will add execute “make fipsinstall” during the product installation to
> generate the fipsmodule.cnf.
>
> Since customer can install product to anywhere and “make fipsinstall”
> can also install fipsmodule.cnf to anywhere and openssl library won’t
> know the location.
>
> So I can’t successfully load FIPS provider because it doesn’t know where
> is the fipsmodule.cnf. Per my test, it seems to find fipsmodule.cnf in
> pre-fix path configure in compile.
>
> My key point is: is there a method to let openssl know where to
> load/check fipsmodule.cnf?
>
> *From:* openssl-users <openssl-users-bounces@xxxxxxxxxxx> *On Behalf Of
> *pauli@xxxxxxxxxxx
> *Sent:* Friday, June 30, 2023 15:16
> *To:* openssl-users@xxxxxxxxxxx
> *Subject:* Re: questions on fips provider
>
> *EXTERNAL EMAIL*
>
>
>
> 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-moduleoption, 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
>
> ================================
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support:
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences
> - http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
> ================================
>
> This communication and any attachments may contain confidential
> information of Rocket Software, Inc. All unauthorized use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> please notify Rocket Software immediately and destroy all copies of this
> communication. Thank you.
>
