Programmatic Execution of the "OpenSSL-fipsinstall" Command

[Thomas Dwyer III]

When you say programmatically, do you mean executing literally the 
"openssl fipsinstall" command with suitable arguments, or do you mean 
running an equivalent replacement program? We do the latter, in a 
slightly different way than the OpenSSL documentation provides. We 
cross-compile OpenSSL on x86_64 for an embedded 32-bit ARM platform so 
it's not possible for us to execute fipsinstall as part of our build 
process (and non-compliant anyway since coping fipsmodule.cnf to other 
systems is not allowed). Also, flash space constraints prohibit us from 
including the large openssl binary in our images. And then there's the 
chicken-egg situation with shipping a static configuration file that 
".include"s a nonexistent fipsmodule.cnf.

Our solution was to ship a static configuration file that contains:

     [fips_sect]
     .include /path/to/fipsmodule.cnf

where fipsmodule.cnf (initially empty) resides in a smaller writable 
location of flash separate from where most other things live. On first 
boot we detect that fipsmodule.cnf is empty and we run a very small 
standalone fipsinstall replacement that loads the FIPS provider, runs 
the self-tests, and generates the same contents as "openssl fipsinstall" 
but without the [fips_sect] header. This solves the problem of using 
libcrypto with a syntactically incorrect configuration (i.e. where 
[provider_sect] in the static openssl.cnf references [fips_sect] which 
doesn't exist yet). Finally, we let the administrator toggle FIPS on/off 
by storing a persistent flag that gets read by a constructor that we 
added to libcrypto:

     void __attribute__ ((constructor)) fipsmode(void)
     {
         int mode = {fetch value of persistent flag}
         EVP_default_properties_enable_fips(NULL, mode);
     }

Note that a forced reboot is required when toggling this flag since the 
change won't apply to any instances of libcrypto already loaded by 
running processes.

We can get away with this because we don't use OpenSSL's FIPS 
certificate--we send our implementation through CMVP and get our own 
certificate. That's probably cost-prohibitive for smaller organizations.


Tom.III


On 11/21/23 02:05, meera pulse wrote:
>
> Hello,
>
> I am currently working on a project that involves the use of the 
> "OpenSSL-fipsinstall" command, and I'm exploring the possibility of 
> running it programmatically. I would appreciate some guidance on the 
> steps involved and whether this approach is feasible.
>
> Has anyone successfully executed the "OpenSSL-fipsinstall" command 
> programmatically?
>
> What steps need to be taken to achieve programmatic execution of 
> "OpenSSL-fipsinstall"?
>
> Are there any potential challenges or considerations that I should be 
> aware of?
>
> I'm eager to hear from anyone with experience or insights into this 
> matter. Your assistance will be invaluable in helping me navigate 
> through this aspect of my project.
>
> Thank you in advance for your time and expertise!
>
> Thanks,
>
> Memo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20231121/fa8bc3ec/attachment-0001.htm>