openssl fipsinstall

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

openssl fipsinstall

Thomas Dwyer III
Hi all,

I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment with very limited flash space. We need and use libcrypto and libssl but we have no need for the openssl binary. To date it was never necessary to ship this utility in our product. Now with OpenSSL 3.0 it appears the only way to get FIPS support is to run "openssl fipsinstall ..." to create a FIPS config file to be included by the main config file. However, at nearly 1MB in size this binary is prohibitively large.

I am able to reproduce the output of "openssl fipsinstall ..." with a (considerably smaller) standalone tool that links with libcrypto and generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm unclear on what the actual FIPS requirements are for this. Would I still be considered FIPS compliant if I use my own standalone tool instead of the openssl binary to generate the FIPS config? I presume I don't need to bother with the self-test callback and that it only matters whether or not OSSL_PROVIDER_load(NULL, "fips") succeeds?


Thanks,
Tom.III

Reply | Threaded
Open this post in threaded view
|

Re: openssl fipsinstall

Dr Paul Dale
These are questions better asked of a FIPS lab since they are the experts and we are not.

I expect that your alternative installation process’s validity will depend on the security policy and what it says needs to be done.  This hasn’t been written yet so there is no answer at this point.

Skipping the self tests is definitely not permitted.  The full suite of self tests *must* be run before the module can be used.


You question prompts the possibility of making fipsinstall a standalone executable, this is something we could look into if we get time.  I expect we’d look favourably on a pull request that allowed either or both options.

Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




On 28 Jul 2020, at 6:19 am, Thomas Dwyer III <[hidden email]> wrote:

Hi all,

I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment with very limited flash space. We need and use libcrypto and libssl but we have no need for the openssl binary. To date it was never necessary to ship this utility in our product. Now with OpenSSL 3.0 it appears the only way to get FIPS support is to run "openssl fipsinstall ..." to create a FIPS config file to be included by the main config file. However, at nearly 1MB in size this binary is prohibitively large.

I am able to reproduce the output of "openssl fipsinstall ..." with a (considerably smaller) standalone tool that links with libcrypto and generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm unclear on what the actual FIPS requirements are for this. Would I still be considered FIPS compliant if I use my own standalone tool instead of the openssl binary to generate the FIPS config? I presume I don't need to bother with the self-test callback and that it only matters whether or not OSSL_PROVIDER_load(NULL, "fips") succeeds?


Thanks,
Tom.III


Reply | Threaded
Open this post in threaded view
|

Re: openssl fipsinstall

Thomas Dwyer III
On Mon, Jul 27, 2020 at 3:39 PM Dr Paul Dale <[hidden email]> wrote:
These are questions better asked of a FIPS lab since they are the experts and we are not.



That is a fair response.


I expect that your alternative installation process’s validity will depend on the security policy and what it says needs to be done.  This hasn’t been written yet so there is no answer at this point.

Skipping the self tests is definitely not permitted.  The full suite of self tests *must* be run before the module can be used.



Oops, I didn't mean to suggest skipping the self-tests. I was talking about the callback that fipsinstall currently uses to display results and/or inject faults in the self-tests. I don't think I need that. As long as OSSL_PROVIDER_load() succeeds it seems safe (?) to assume that all the self-tests passed at some point.



You question prompts the possibility of making fipsinstall a standalone executable, this is something we could look into if we get time.  I expect we’d look favourably on a pull request that allowed either or both options.



This is encouraging. However, since there is no draft security policy written yet would this be premature? Or are you suggesting that the presence of a standalone tool might influence the contents of such a security policy?


Thanks,
Tom.III



Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




On 28 Jul 2020, at 6:19 am, Thomas Dwyer III <[hidden email]> wrote:

Hi all,

I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment with very limited flash space. We need and use libcrypto and libssl but we have no need for the openssl binary. To date it was never necessary to ship this utility in our product. Now with OpenSSL 3.0 it appears the only way to get FIPS support is to run "openssl fipsinstall ..." to create a FIPS config file to be included by the main config file. However, at nearly 1MB in size this binary is prohibitively large.

I am able to reproduce the output of "openssl fipsinstall ..." with a (considerably smaller) standalone tool that links with libcrypto and generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm unclear on what the actual FIPS requirements are for this. Would I still be considered FIPS compliant if I use my own standalone tool instead of the openssl binary to generate the FIPS config? I presume I don't need to bother with the self-test callback and that it only matters whether or not OSSL_PROVIDER_load(NULL, "fips") succeeds?


Thanks,
Tom.III


Reply | Threaded
Open this post in threaded view
|

Re: openssl fipsinstall

Dr Paul Dale
The fipsinstall program runs the platform tests.  I.e. you need to run fipsinstall on the device at some point.


> Or are you suggesting that the presence of a standalone tool might influence the contents of such a security policy?

Yes.  Well maybe.  I’ll posit the possibility at the next planning meeting.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




On 28 Jul 2020, at 9:51 am, Thomas Dwyer III <[hidden email]> wrote:

On Mon, Jul 27, 2020 at 3:39 PM Dr Paul Dale <[hidden email]> wrote:
These are questions better asked of a FIPS lab since they are the experts and we are not.



That is a fair response.


I expect that your alternative installation process’s validity will depend on the security policy and what it says needs to be done.  This hasn’t been written yet so there is no answer at this point.

Skipping the self tests is definitely not permitted.  The full suite of self tests *must* be run before the module can be used.



Oops, I didn't mean to suggest skipping the self-tests. I was talking about the callback that fipsinstall currently uses to display results and/or inject faults in the self-tests. I don't think I need that. As long as OSSL_PROVIDER_load() succeeds it seems safe (?) to assume that all the self-tests passed at some point.



You question prompts the possibility of making fipsinstall a standalone executable, this is something we could look into if we get time.  I expect we’d look favourably on a pull request that allowed either or both options.



This is encouraging. However, since there is no draft security policy written yet would this be premature? Or are you suggesting that the presence of a standalone tool might influence the contents of such a security policy?


Thanks,
Tom.III



Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




On 28 Jul 2020, at 6:19 am, Thomas Dwyer III <[hidden email]> wrote:

Hi all,

I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment with very limited flash space. We need and use libcrypto and libssl but we have no need for the openssl binary. To date it was never necessary to ship this utility in our product. Now with OpenSSL 3.0 it appears the only way to get FIPS support is to run "openssl fipsinstall ..." to create a FIPS config file to be included by the main config file. However, at nearly 1MB in size this binary is prohibitively large.

I am able to reproduce the output of "openssl fipsinstall ..." with a (considerably smaller) standalone tool that links with libcrypto and generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm unclear on what the actual FIPS requirements are for this. Would I still be considered FIPS compliant if I use my own standalone tool instead of the openssl binary to generate the FIPS config? I presume I don't need to bother with the self-test callback and that it only matters whether or not OSSL_PROVIDER_load(NULL, "fips") succeeds?


Thanks,
Tom.III