questions on fips provider

Fri Jun 30 08:16:56 UTC 2023

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 at openssl.org> *On Behalf Of 
> *pauli at openssl.org
> *Sent:* Friday, June 30, 2023 15:16
> *To:* openssl-users at openssl.org
> *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.
> 