Need Help on OpenSSl 3.0.x and FIPS enablement

[Tomas Mraz]

Yes, the current security policy does not allow for anything else. And
to be compliant you must follow it precisely.

On the other hand, fipsmodule.cnf as generated by the build process
actually does not contain the configuration file checksum which
triggers running the selftest every time the fips module is loaded.

So it would be actually possible to modify the security policy document
to allow that _incomplete_ fipsmodule.cnf to be used without running
fipsinstall on every deployed platform at the cost of having the full
set of selftests run on every fips module load.

Tomas

On Thu, 2023-03-02 at 19:45 +1100, Dr Paul Dale wrote:
>  You **must** run the fipsinstall program on every device that you
> want to claim as FIPS validated.  This means that it must be
> installed & executed on each and every platform.  There is no room
> for maneuver here.  Obey the security policy to the letter or not be
> FIPS.  Deeply embedded platforms do **not** get an exception and
> never have.
>  
>  If you want to discuss things further, you should engage with your
> FIPS lab.
>  
>  Pauli
>  
> On 2/3/2023 7:34 pm, Prasad, PCRaghavendra wrote:
>  
> > Hi Paul,
> >  
> > Thanks for the information.
> >  
> > We will go through the documents once again for more understanding.
> >  
> > One basic doubt is when we deploy/build OpenSSL on our  build
> > machine with FIPS enabled (enable_fips) which will generate
> > fips.dll/so and fipsmodule.cnf.
> > We then change the openssl.cnf to access the fipsmodule.cnf and
> > enable fips on the build machine and execute the application or do
> > it programmatically to load the fips module and run the
> > application.
> >  
> > As for running on different machines to the build one, the security
> > policy [csrc.nist.gov] is clear that the checksum configuration
> > cannot be copied between machines:
> >  * But we carry libssl.so and libcrypto.so in our build artifacts
> > till now and activate the fips at run time in our application
> > (OpenSSL 1.0.2 FIPS)  on different machines (customer machines) as
> > we are embedded software, so how it can be achieved using OpenSSL
> > 3.0.x + FIPS versions? how can we achieve FIPS on different
> > machines but built on one machine? Is it possible
> >  
> > Can you please throw some input on this?
> >  
> > Thanks,
> > Ragahvendra
> >  
> >  
> > From: openssl-users <openssl-users-bounces at openssl.org> On Behalf
> > Of Dr Paul Dale
> >  Sent: Wednesday, March 1, 2023 3:34 AM
> >  To: openssl-users at openssl.org
> >  Subject: Re: Need Help on OpenSSl 3.0.x and FIPS enablement
> >  
> > [EXTERNAL EMAIL] 
> > Have you read the relevant documentation?  Specifically, the FIPS
> > module guide [openssl.org], the FIPS provider [openssl.org] and the
> > migration guide [openssl.org]?  These answer most of your questions
> > and can be easy to miss.
> >  
> >  With the FIPS provider in OpenSSL 3.0 you will not be able to
> > escape having some configuration in a file.  The FIPS provider does
> > an integrity check on start up and the correct checksum comes from
> > configuration.
> >  
> >  As for running on different machines to the build one, the
> > security policy [csrc.nist.gov] is clear that the checksum
> > configuration cannot be copied between machines:
> >  
> > > Note: The Module shall have the self-tests run, and the Module
> > > config file output generated on each platform where it is
> > > intended to be used. The Module config file output data shall not
> > > be copied from one machine to another.
> > I'll note that following the build and installation instructions
> > from in the security policy [csrc.nist.gov] is necessary for a FIPS
> > compliant provider.
> >  
> >  
> >  Pauli
> > On 1/3/23 04:52, Prasad, PCRaghavendra via openssl-users wrote:
> >  
> > > Hi Team,
> > >  
> > > Our team has started migrating from OpenSSL 1.0.2 to OpenSSL
> > > 3.0.x version.
> > > We are doing POC for the same on windows and Linux.
> > >  
> > > We have a tight schedule to finish the migration by April 1st
> > > week as we need to fix one critical BD issue and support TLS 1.3
> > > feature as well.
> > >  
> > > The team and I are going through multiple docs of OpenSSL 3.x and
> > > trying to figure out how to configure fips once we build the
> > > OpenSSL.
> > >  
> > > Few things:
> > >    1. In openssl 3.0.x Fips module is installed/integrated by
> > > default (enable-fips) during the build step
> > >    2. Fipsmodule.cnf is present in the default location
> > > (c:\usr\local\ssl\)
> > >    3. After reading multiple ways on how to enable fips, one way
> > > is the config way where we need to change few params in
> > > openssl.cnf
> > >    4. By changing that and we did the test using openssl.exe (
> > > sha1 passed and md5 failed) all good
> > >    5. Now the challenge is we need to set the fips enablement
> > > programmatically which we were going through multiple docs
> > > (openssl and some forums)
> > >    6. Till now we used OpenSSL 1.0.2 where the fipsmodule is
> > > embedded in libcrypto and we need to set it at the beginning of
> > > the application (fips_mode_set()) and everything else is taken
> > > care by default.
> > >    7. Now with OpenSSL 3.0.x how to set that fips mode for the
> > > entire application is not very clear
> > >    8. Very where they are talking about the config files, our
> > > application is a standalone application that bundles all the
> > > required libs(crypto/SSL) and runs on its own, it will not refer
> > > to any system config/lib files
> > >    9. So our doubt is if we build on the application on build
> > > machine containing OpenSSL 3.0.x and create an artifact. We need
> > > to run on different machines.
> > >   10. In OpenSSL 3.0.x is there any hard dependency on the .cnf
> > > files should we carry them in our artifact and if so should we
> > > install them in the default path like ( C:\usr or /us/local)
> > > which we were not doing till now?
> > >  
> > > Any input on this will be really helpful
> > >  
> > > Thanks,
> > > Raghavendra
> > >  
> > > Internal Use - Confidential
> >  
>  

-- 
Tomáš Mráz, OpenSSL