Some of you may have noticed that the upcoming 1.1 release doesn’t include any FIPS support. That omission is not by choice; it was forced on us by circumstances and will hopefully not be permanent.

The v2.0 OpenSSL FIPS module is compatible with the 1.0.x releases, in particular the 1.0.2 “LTS” release that will be supported through 2019. It has proven very popular, used both directly by hundreds of software vendors and indirectly as a model for copycat “private label” validations.

Unfortunately the restructuring done for the 1.1 release means that the v2.0 module can’t be used without contortions that don’t belong in a cleaner and better OpenSSL. We’d like to do a new FIPS module for 1.1 with a new validation to succeed the v2.0 module, but the open source based FIPS 140-2 validations present some extraordinary challenges. Only five such validations have ever been done, out of over twenty four hundred validations, and I’ve been at ground zero for each of them.

Conventional proprietary validations of closed source software modules are relatively easy; not so for the open source based ones even when the code is exactly the same. Those open source based validations take a lot of time, manpower, and money. They also involve a large amount of risk; for those five validations to date we invested those resources without knowing if or when a validation would be obtained. Once obtained, the validations can be (or could be) extended repeatedly at lower risk and cost to include new platforms; thanks to several dozen sponsors the v2.0 module now has over a hundred platforms.

I’ve been looking for sponsorship of a new validation almost since the v2.0 validation was obtained in 2012. Those first five open source based validations each had one or more U.S. government agencies as primary sponsors, an ideal situation as the sponsor incentives align closely with ours. But, we have no such sponsorship prospects at present.

Commercial sponsorship is a possibility. I’ve spent most of this year in discussions with several commercial software vendors willing to cover the substantial costs of a new validation. Understandably enough they would do so only on the basis that we first obtain a validation that they could use themselves, leaving us with ownership of the code and documentation and free to pursue our own open source based validation after a limited period of exclusivity. That struck me as a reasonable tradeoff, and recently we came close to signing such a deal.

In the meantime however it has become increasingly clear that our prospects for obtaining a new open source based validation are very marginal. The CMVP, the government bureaucracy responsible for FIPS 140-2 validations, has instituted new practices and policies inimical to the inherently collaborative nature of open source based validations. That issue has been discussed in detail elsewhere; the TL;DR is that the risks and uncertainties have soared to the point where it is no longer logistically or economically feasible to do the kind of collaborative effort where the contributions of multiple unrelated sponsors are pooled for one shared validation.

So, what would have to happen to make a new validation effort possible? A rather forbidding set of requirements:

• Funding to pursue a new open source based validation effort, win or lose. I estimate that will cost about a third of a million dollars, though there is huge uncertainty in that estimate. In the past we did these validations “at risk”, meaning we gambled that we’d obtain the validation and make up the cost with subsequent platform additions. I won’t speak for my colleagues but I am no longer willing to take that risk.

• Sponsor(s) willing to wait until the open source based validation is successfully completed; this could take two or more years (longer than the typical proprietary validation, even of the same code).

• Sponsor(s) willing and and able to champion the open source based validation within the Department of Commerce (DoC). I’m not privy to all the details, nor do I want to be, but I am aware that the prior validations involved intercession by sponsors at various levels within DoC. There have always been vested interests hostile to the open source based validations, and without a counter to that opposition I do not believe the prior validations would have succeeded.

I don’t have high hopes that we’ll see that white knight sponsor anytime soon. So for now we watch and wait and hope for the right opportunity. I’m not giving up entirely, though. After tilting at the FIPS 140-2 windmill for over a decade I know endless patience is a must.

In the meantime we’re already being asked by multiple commercial interests to assist in their pursuit of proprietary closed source validations. That’s a tough one, but as much as we’d like to be all things to all people we are an organization with limited resources and need to allocate those resources effectively to benefit the greater community. We can justify expending resources for open source based validations that benefit a wide range of the user community. We can’t justify that impact for a handful of U.S. vendors. Contributions of FIPS specific code and updates to handle FIPS specific issues are unlikely to be added into an OpenSSL repository until we have an actual use for them.