As mentioned in a previous
blog post, OpenSSL team members met with various representatives of the FIPS
sponsor organisations back in September last year to discuss design and planning
for the new FIPS module development project.
Since then there has been much design work taking place and we are now able to
publish the draft design documentation. You can read about how we see the longer
term architecture of OpenSSL changing in the future
here and you
can read about our specific plans for OpenSSL 3.0 (our next release which will
include a FIPS validated module)
here.
OpenSSL 3.0 is a major release and will be a significant change to the internal
architecture of OpenSSL. We plan to keep impacts on existing end user
applications to an absolute minimum with the intention that the vast majority of
existing well-behaved applications will just need to be recompiled. No
deprecated APIs will be removed in this release.
The biggest change will be the introduction of a new concept known as
Providers. These can be seen as a replacement for the existing ENGINE
interface and will enable much more flexibility for implementors. libcrypto
gives applications access to a set of cryptographic algorithms, while different
Providers may have different implementations of those algorithms.
Out-of-the-box OpenSSL will come with a set of Providers available. For example
the “default” Provider will implement all of the most commonly used algorithms
available in OpenSSL today. There will be a “legacy” Provider that implements
legacy cryptographic algorithms and a FIPS Provider that implements FIPS
validated algorithms. Existing engines will still work (after a recompile) and
will be made available via both the old ENGINE APIs as well as a Provider
compatibility layer.
The new design incorporates the FIPS module into main line OpenSSL. It will no
longer be a separate download and support periods will also be aligned. It will
of course be possible to build OpenSSL with or without the FIPS module depending
on your own individual circumstances and requirements.
The FIPS module version number will be aligned with the main OpenSSL version
number. OpenSSL 3.0.0 will incorporate the 3.0.0 FIPS module. Not every release
of OpenSSL will necessarily lead to an update in the FIPS module version number
so there may be “gaps”. For example OpenSSL 3.0.1 might still provide and work
with the 3.0.0 module.
New APIs will be introduced to give applications greater flexibility in the
selection of algorithm implementations. Of course support will be maintained for
existing APIs so applications don’t need to use the new APIs if they don’t want
to. For example applications will be able to set different algorithm selection
criteria for different SSL_CTXs. This might be used to enforce selection of FIPS
validated algorithms for one SSL_CTX, while allowing another SSL_CTX to use
default implementations.
There is much still to be done to make this new OpenSSL design a reality.
However with the publication of these design documents we are encouraged to see
that pull requests are already starting to come in to make the necessary changes
to the code. We expect the coming months to be very active amongst the
development community as we head towards alpha and beta releases later on this
year.
https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
