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