A joint U.S. and Canadian organization that certifies encryption tools for use by federal government agencies has suspended its validation of OpenSSL cryptographic technology for the second time in less than six months.
The decision means that government agencies cannot purchase the open-source tool for the time being, although those that have already done so will still be allowed to use it. OpenSSL is an open-source implementation of the Secure Sockets Layer (SSL) and Transport Layer security protocols. It is widely used to encrypt and decrypt data on the Internet.
The decision to suspend validation of the tool came just two days after the group doing the validation, Cryptographic Module Validation Program (CMVP), had taken the harsher step of revoking the tool entirely. It backed away from that decision and opted for a suspension of the process instead.
News of the rapid changes to the validation effort drew criticism from theHattiesburg, Miss.-based Open Source Software Institute (OSSI), a non-profit group trying to get the OpenSSL encryption module validated for use in government. John Weathersby, OSSI’s executive director, Wednesday alleged that the move appears to have been influenced by vendors of proprietary technologies who stand to lose a lucrative market if an open source alternative is certified.
“There are some vendors fighting like hell to make this die, and I can see why,” said Weathersby. “What’s going on is the question of the day. This is not a technology issue, this is a political issue.”
OpenSSL is supported on several major platforms, including many flavors of Unix, Apple Computer Inc.’s Mac OS X and Microsoft’s Windows.
OpenSSL received its precedent-setting validation in January from the CMVP, which is charged with validating and certifying that cryptographic tools sold to government agencies meet the requirements of the Federal Information Processing Standard (FIPS) publication 140-2. The CMVP was established by the U.S. National Institute of Standards and Technology (NIST) and the Communications Security Establishment of the Canadian government.
A validated OpenSSL tool would allow OS vendors, Web browser makers and vendors of other software products such as e-mail to include a free FIPS-140 compliant cryptographic module. The OpenSSL FIPS 140-2 validation effort is sponsored by the Defense Medical Logistics Standard Support (DMLSS) program, which provides medical logistics support to the U.S. Department of Defense.
Currently, agencies looking for encryption capabilities spend hundreds of thousands of dollars — and in some cases, millions of dollars — licensing proprietary crypto tools that are FIPS 140 certified.
Since January, however, the validation for Open SSL has been revoked and reinstated twice, Weathersby said. The first revocation happened in January, barely four days after OpenSSL was first validated by CMVP. It was awarded a FIPS 140-2 validation again in March after some changes were made to the module.
On Friday, OSSI was told that the validation had again been revoked, Weathersby said. That changed yesterday, when the organization learned that the OpenSSL certificate had been incorrectly “revoked” and is now instead “not available.” That means that the OpenSSL cryptographic module can no longer be bought by government agencies, although it can be used by those that already have it.
NIST, in an e-mailed statement, confirmed the “not-available” status but offered no reasons for it. “However, if non-compliance is discovered in a module after it has been validated, and based on a risk assessment it is deemed to be critical, the CMVP will advise all federal agencies to cease using the affected module,” NIST said.
A representative from DOMUS IT Security Laboratory, the Ottawa Canada-based company that is evaluating products for FIPS 140 compliance, referred all questions to the CMVP.
The continuing uncertainly about the status of OpenSSL is sure to prolong what has been a multi-year effort to certify the tool. Much of the delay resulted from a continuing series of tweaks OSSI was required to make to the cryptographic module at the request of the CMVP, said Steve Marquess, validation project manager at OSSI.
Part of the problem stems from the fact that the FIPS requirements were written for hardware-based encryption tools while OpenSSL is software-based. As a result, mapping FIPS’ requirements to OpenSSL has proved challenging, Marquess said.
Vendors of commercial products have also raised a constant stream of technology-related questions that have proved time consuming to address.
“There have been some commercial interests who are unhappy with open-source validation like this,” Marquess said. “One of them has been working for several years to challenge multiple aspects of what we are trying to do,” he said without naming the vendor.
One of the results is that the requirements for OpenSSL to get FIPS 140-2 validation has keeps changing he said. “One of our frustrations through this whole ordeal is pinning down the requirements in concrete technical terms,” he said. “The requirements keep changing on us all the time.”
George Adams, the president and CEO of SSH Communication Security, a Wellesley, Mass.-based vendor of encryption products, said that concerns about the use of OpenSSL in government environments are valid. As an open-source tool, OpenSSL is subject to constant changes that would invalidate its certification on a regular basis, he said.
For instance, any changes made to the source or linked library in the cryptographic module will create a non-validated module, he said. Similarly, any additional cryptography outside of the validated module would need to be tested and validated.
Marquess dismissed such concerns. He said that the security policy associated with OpenSSL guarantees that the source code used to generate the cryptographic module is unmodified at all times.
