How can OpenSSL survive FIPS 140-2 validation in 2020?

by Stephan Mueller

The OpenSSL project outlined the development strategy pertaining to the Federal Information Processing Standard (FIPS) 140-2 code in the November 7^th, 2019 OpenSSL blog titled “Update on 3.0 Development, FIPS and 1.0.2 EOL.”[1] As a summary, the following relevant aspects for FIPS 140-2 are communicated.

·     The standard OpenSSL 1.0.2 will be End of Life at the end of 2019. The FIPS compliant version based on version 1.0.x is the OpenSSL FIPS Object Module 2.0.x, which is therefore also End of Life by the end of 2019.

·     The current version of the standard OpenSSL library is 1.1.1 and is considered the version with long-term support. The development team suggests that all users move to this version. The FIPS compliant version based on 1.1.1 will be the OpenSSL FIPS Object Module 3.0. However, although the standard OpenSSL version 1.1.1 has been available for some time already, the FIPS Object Module 3.0 will become available in Q4 2020 according to [1].

With this communication, there is a significant gap for users requiring a FIPS compliant OpenSSL code base between the end of 2019 and Q4 2020. This begs the question on how to bridge that gap. The following strategy outlines different approaches that could be applied to have continuous FIPS 140-2 coverage of even current versions of OpenSSL in 2020 and beyond.

One solution, which may be a challenge for a large number of customers, could be to maintain the OpenSSL 2.0.x code base further without the help of the upstream community. This would imply that at least security relevant patches added to version 1.1.1 would need to be backported. In addition, by following this approach, the Common Vulnerabilities and Exposures (CVE) list should be monitored and potentially new CVEs would need to be addressed by developing independent patches in-house. With such an approach, a user would basically create and maintain a fork of the existing OpenSSL code base. This would mean that such a user must have strong knowledge in cryptography to ensure changes do not weaken existing cipher implementations.

A more practical solution could be to switch to the OpenSSL versions made available by the Linux distributions Red Hat Enterprise Linux (RHEL) 8, SUSE Linux Enterprise Server (SLES) 15 or Ubuntu 18.04. These distributions took the OpenSSL 1.1.1 standard code base and forward-ported all FIPS 140-2 patches. The resulting OpenSSL 1.1.1 versions provided by the mentioned distributions attempt to be API (Application Program Interface) and ABI (Application Binary Interface) compatible to the standard OpenSSL 1.1.1 library and yet utlize FIPS 140-2 compliant cipher implementations. When using an OpenSSL version from these distributions, applications may hardly need any changes when they already link to the standard OpenSSL version 1.1.1. When switching to one of these distributions' OpenSSL code, the user also benefits from an active maintenance of the code base including addressing of any security-relevant or non-security-relevant bugs. Such an approach may require much less development effort than maintaining a fork of an older OpenSSL code base. Also, this approach may provide a more stable OpenSSL code base compared to maintaining a separate fork of OpenSSL.

atsec has been working with Red Hat, SUSE and Canonical for many years to have their major releases of cryptographic modules continuously covered under FIPS certification. When using the OpenSSL 1.1.1 code base provided by the mentioned Linux distributions, atsec is capable of providing Automated Cryptographic Validation Protocol (ACVP) testing out of the box since the atsec-maintained ACVP tool set covers all cipher implementations and utilizing all required APIs of these OpenSSL versions.

[1] https://www.openssl.org/blog/blog/2019/11/07/3.0-update/