It’s been almost a year since plans for a new FIPS 140 validation were
Several factors have led to this long delay. For one, we chose to focus
our limited manpower resources on higher priority objectives such as the
TLS 1.3 implementation. SafeLogic has also experienced difficulties in
obtaining the funding for their intended sponsorship; potential sponsors can
contact them directly.
With TLS 1.3 now done (pending only a final TLS 1.3 specification) we’re
now in a position to turn our attention to the new FIPS module, and just
in the nick of time Oracle has pledged enough funding to get us off to a
good start. With financial support from the Linux Foundation Core
Infrastructure Initiative temporarily interrupted, leaving a team member with
no income, that funding eases the pressure to seek new long term employment.
The bad news is that the Oracle funding will only partially cover the FIPS module
work (for perhaps a couple of months), at which point we may have to set that work
aside. Hand-to-mouth funding is not a new experience for us though so
we’ll worry about that later.
The FIPS module is heavily shaped and constrained (one could even say
distorted and contorted) by FIPS 140 requirements. Those requirements (or
technically speaking the interpretation of those requirements) has
changed considerably since our last open source based validation in
2013, so we’re starting with a careful study of the many requirements
changes that have accumulated since then. That study will generate a lot
of questions for the accredited test lab, as the practical application
of the formal requirements to working code is rarely obvious to anyone.
One goal for this new FIPS module is to make a clean break from the
legacy code base of the previous module, which started as a stripped and
bastardized version of an old copy of OpenSSL. We’ll be making the new
module as simple as possible without extraneous vestigial code. It will
live in a new separate git repository, though don’t expect to
see a lot of code right away as we work through the requirements questions.
As before the FIPS module will be primarily intended for use with
OpenSSL proper, though we hope to minimize (or even eliminate) FIPS
specific code in OpenSSL by enhancing the current ENGINE interface. The
new FIPS module will have an internal API (with non-opaque structures)
that in turn will be wrapped in a higher level ENGINE interface package
external to the “cryptographic module boundary”. All three components
(formal validated module, module interface wrapper, and OpenSSL proper)
will as before be usable as a seamless “FIPS capable” OpenSSL library.
The test suite software will interface with the module directly, and
that code will be separate from the module itself. We’ll be sorting out
the outlines of these separate components as soon as we’ve confirmed we
understand the new requirements.
I’ll blog more as we finalize additional details.