After the Heartbleed bug in 2014 showed how widely used OpenSSL was -- practically all of the internet scrambled to patch applications -- the project team committed to reworking and improving the popular open source encryption package. The resulting work, OpenSSL 1.1, is a dramatic restructuring of the encryption software and appears to be a significant improvement over the current version.
Yet the extensive code rework means OpenSSL 1.1, currently in beta testing, faces a significant adoption challenge after its public release: The cryptographic module for OpenSSL 1.1 is currently not FIPS-140-2 validated, which means government agencies will not be allowed to use the new version.
FIPS 140-2 is the only encryption standard recognized by the National Institutes of Standards and Technology, and federal agencies are not allowed to use any encryption products that have not been FIPS-validated. While the current version of OpenSSL's cryptographic module is FIPS-validated, the code changes means the cryptographic module in OpenSSL 1.1 needs to undergo the validation process again and get revalidated.
Validation is a time-consuming and expensive process, as the module has to be built, tested by a third-party laboratory, and certified by NIST as meeting the requirements outlined in FIPS-140-2. OpenSSL worked with government sponsors for previous versions -- DARPA sponsored the last one -- but no such sponsor had stepped up to take version 1.1 through what Steve Marquess, president of OpenSSL Validation Services, the business unit of the OpenSSL project, once called a "fickle and unpredictable" process. Without a "white knight" sponsor, a new FIPS 140-2 validated module for OpenSSL 1.1 would not happen, Marquess said in a September 2015 blog post.
The knight riding to OpenSSL's rescue is encryption company SafeLogic, which committed last week to "sponsor a new FIPS validation on ‘truly open or bust' terms," Marquess said.
To be clear, the lack of FIPS validation wouldn't hold up beta testing or the public release for OpenSSL 1.1, and most organizations would be able to use the improved and secure OpenSSL 1.1 with the standard cryptographic module without any problems.
However, federal agencies and organizations working with government contracts subject to NIST requirements would have to remain with OpenSSL 1.0.1 or 1.0.2 and the FIPS-validated cryptographic modules used by those versions. SafeLogic's move makes it possible for the OpenSSL team to begin the validation process so that once complete, government agencies and contractors can also use OpenSSL 1.1.
If OpenSSL 1.1 is a newer and better model of a car, the cryptographic module built to FIPS specifications would be like adding a racing engine to that new model, said Walter Paley, director of marketing for SafeLogic.
While anyone can keep using OpenSSL 1.1 with the standard module, no one -- not even SafeLogic -- can use the new FIPS module until NIST finishes the process and the open-source-based validation is available for everyone. At that point, organizations that have adopted OpenSSL 1.1 can also switch to using the validated module.
"The availability of an OpenSSL 1.1 FIPS module will provide greater security in regulated verticals and more opportunities for everyone working in this community," Ray Potter, CEO and founder of SafeLogic explained in a blog post. Organizations that aren't required to use the FIPS-validated module will be able to do so and reap the security benefits of making that switch.
"As a team, we believe that a rising tide lifts all boats," Potter wrote.
Now that there is a sponsor, the project team can finish working on the cryptographic module that will undergo the validation process. The team will take the standard cryptographic module that is currently part of the OpenSSL 1.1 beta and add stricter controls and checks required under FIPS rules. At the core, there will be no difference between the standard cryptographic module and the FIPS module, but some changes are necessary to meet the requirements.
Once this new version is ready, SafeLogic will check over the code to make sure it is ready before submitting it for validation to Acumen Security, a testing laboratory that will review the code. Acumen will send the results to NIST's Cryptographic Module Validation Program office, which will then issue the validation.
"The OpenSSL team will complete the code changes required to operate in FIPS mode while SafeLogic will manage the project, handle the documentation and validation process, provide technical and strategic assistance, and fund the effort," Potter said.
Marquess called the team working on this validation effort -- SafeLogic technical lead Mark Minnoch, Acumen Security, and the OpenSSL developers Steve Henson and Andy Polyakov -- his "dream team."
"This validation sponsorship [with SafeLogic] is very unusual and something most commercial companies would be completely incapable of even considering," Marquess wrote, noting that multiple commercial vendors had already offered to fund the validation effort, but had requested some kind of proprietary access or a period of exclusivity in exchange.
The sponsorship deal benefits OpenSSL and the user community, but there isn't a clear win for SafeLogic. Of course, SafeLogic's central role in the validation process means it will be the only company with the expertise and knowledge in the design, operation, and validation of OpenSSL 1.1 modules. That knowledge can be used to improve future versions of the company's encryption products. "We are happy to put in the sweat equity on the open source communal validation," knowing the effort will pay off later, Potter wrote.
There is nothing wrong with federal agencies staying with version 1.0.2 -- it is under support until 2019 -- except for one pretty big problem. Transport Layer Security protocol uses OpenSSL, and the new TLS 1.3 with significant security and privacy improvements specifically requires OpenSSL 1.1.
While TLS 1.3 is expected to soon be mandatory for the Department of Defense and other federal agencies, that becomes an impossible mandate if there is no open source FIPS-104-2 validated module for OpenSSL 1.1. It's possible someone could have built a proprietary FIPS module to fill the void for specific agencies, that wouldn't help organizations who rely upon the open source module.
"We were headed toward a serious catch-22," Potter said in an email. "The pipeline of exciting new products that are getting approval for federal use would have been threatened, and that would have been terrible for everyone."
There isn't a clear deadline for when agencies will begin moving to TLS 1.3, but the FIPS validation has to be well underway before then. So long as NIST recognizes the effort as being "in progress," the migration won't be a problem, Paley said.
SafeLogic declined to specify a timeline for the validation, noting there were too many particulars to be able to make an estimate. Typically, FIPS validation takes a year to year and a half to complete, but Marquess estimated the cryptographic module for OpenSSL 1.1, because of its heavy reliance on open source components, would take two years. SafeLogic said it has completed FIPS validation for its own projects in as short as eight weeks. The timeline for FIPS-module for OpenSSL 1.1 will fall in between the two extremes.
"It is safe to say that we are optimistic we will beat the OpenSSL team's estimate," said Paley.
For many companies, the open source FIPS-validated cryptographic module was a crucial component as it let them work with federal agencies and regulated industries before investing in a proprietary product. Many companies were faced with the "dilemma whether to use the FIPS 140 validated open source module compatible with a rapidly aging, often maligned older version of OpenSSL, or the new, sleek, secure OpenSSL 1.1, but without a FIPS validated module at its heart," Potter wrote.
SafeLogic's move has resolved that dilemma.