FIPS compliance with openssl-1.1.1j

[Michael Wojcik]

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Nagarjun J
> Sent: Friday, 12 March, 2021 06:49

> How to be FIPS compliance with openssl-1.1.1j version , as does not have fips
> object module, is they any ways?

It's possible, in theory; it's even been done. But it's almost certainly not feasible for your organization.

You can port the OpenSSL 1.0.2 FOM to work with 1.1.1; Red Hat and SUSE both did that. Or write your own FIPS-140-compliant crypto layer. Then there's just the small matter of getting it validated, which involves some expense (tens of thousands of dollars) and delay (the CMVP is booked solid for the rest of the year, I hear); and the CMVP probably aren't going to do any more FIPS 140-2 validations after the current batch, now that FIPS 140-3 is here.

If you did get the 1.0.2 FOM working with 1.1.1, it's possible you'd be able to convince some customers to accept a self-validation based on the existing OpenSSL validation. Of course the OpenSSL validation for the existing FOM is on the Historical list, which means it's not supposed to be used for new procurements anyway.

So, in practice, no. Unless you're on Red Hat Enterprise Linux or SUSE Enterprise Linux and can use the FIPS-validated OpenSSL 1.1.1 they supply, I guess. (I assume that's available in some RHEL and SLES releases -- I haven't actually checked. I just know that Red Hat announced they'd done it, and SUSE actually published their patches.)

If it's any consolation, many organizations are in the same boat. We have products which are still shipping FIPS, but that's with an OpenSSL 1.0.2 with Premium Support and in some cases with a substitute FIPS module that we developed years ago and got our own validations for. That's not an option for most people. (I don't blame openssl.org for this state of affairs -- FIPS validations are expensive and resource-intensive, and few OpenSSL consumers support the project. Yes, 3.0 has slipped its original schedule by quite a lot, but better to get it right.)

--
Michael Wojcik