questions on fips provider

[Matt Caswell]

On 30/06/2023 12:38, Ishani wrote:
> 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)?

No. You must use a configuration file.

> 2.  may be using only 1 of them but not both ?

 From a purely technical perspective you can combine them into a single 
file and it would work.

However, the security policy (see Appendix A) requires you to install 
the module via either make install/make install_fips or using openssl 
fipsinstall. All of which create a fipsmodule.cnf file. Whether you 
would still be considered FIPS validated if you subsequently modify the 
file to include it directly in openssl.cnf is unclear and would be a 
question for a FIPS lab.

https://www.openssl.org/source/fips-doc/openssl-3.0.8-security-policy-2023-05-05.pdf

Matt


> 
> 
> On Fri, 30 Jun 2023 at 13:47, Matt Caswell <matt at openssl.org 
> <mailto:matt at openssl.org>> 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 at openssl.org
>     <mailto:openssl-users-bounces at openssl.org>> *On Behalf Of
>      > *pauli at openssl.org <mailto:pauli at openssl.org>
>      > *Sent:* Friday, June 30, 2023 15:16
>      > *To:* openssl-users at openssl.org <mailto: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>
>     <http://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
>     <https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport>
>      > Unsubscribe from Marketing Messages/Manage Your Subscription
>     Preferences
>      > - http://www.rocketsoftware.com/manage-your-email-preferences
>     <http://www.rocketsoftware.com/manage-your-email-preferences>
>      > Privacy Policy -
>     http://www.rocketsoftware.com/company/legal/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.
>      >
>