It’s been almost a year since plans for a new FIPS 140 validation were first announced. 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.