All,
The only response I received about our proposal to try to get certified was from Andreas who said he'd send it off to the Croquet board. After reading this article I really believe that we should try to get certified, if for no other reason then to help the open source community in general.
Is there still an interest in this group to go through this process? If so I will undertake the process of screening all certified labs to find the strongest lab that understands the difficulty and intricacies of open source.
Please respond back and let me know your support for the project and your willingness to participate, or any other comments.
I really think the process will be very beneficial and the challenge you have to admit is a good one.
Thanks!
-Ron Teitelbaum
Security validation of OpenSSL encryption tool uncertain Jaikumar Vijayan
July 19, 2006 (Computerworld) 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 can't 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, the Cryptographic Module Validation Program (CMVP) at the National Institute of Standards and Technology (NIST), 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 the Hattiesburg, Miss.-based Open Source Software Institute (OSSI), a nonprofit group trying to get the OpenSSL encryption module validated for use in government. John Weathersby, OSSI's executive director, today alleged that the move appears to have been influenced by vendors of proprietary technologies that 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 operating systems, including many flavors of Unix, Apple Computer Inc.'s Mac OS X and Microsoft Corp.'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 NIST in the U.S. and the Communications Security Establishment of the Canadian government.
A validated OpenSSL tool would allow vendors of operating systems, Web browsers and 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 cryptographic tools that are certified according to FIPS 140. 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," he said. 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 noncompliance 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 for Domus IT Security Laboratory, the Ottawa-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 multiyear 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 been 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 Communications Security Inc., 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 nonvalidated 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.
Hi Ron,
Sorry for not responding to this earlier, it's been a pretty busy month for me and I'm just now getting around to catching up on email traffic.
I think I'm in a pretty good position to comment on this subject, having worked for the Department of Homeland Security, managing part of their PKI integration process. Somewhere along the line someone also put my name down as a "Federal Smartcard Program Manager." I don't know what that means, but I did do some work with Smart Cards and when I mention it to some people they seem to take it relatively seriously.
FIPS-140-2 is certainly important in the federal government. Laws exist that mandate it's use for certain federal projects. However... it's possible to get waivers for those laws. But FIPS-140-2 isn't the only certification regieme that applications and environments must adhere to. The Common Criteria are increasingly important as are adherence to the FIPS 800 series documents (though the latter are not certification processes in the commonly accepted sense.) Common Criteria covers much more than just crypto and there are Common Criteria for several aspects of system operation.
I think what I'm getting at here is, if you're trying to get a Squeak application approved for use in the US or Canadian federal governments, FIPS is important, but if the application is compelling a waiver can be received. Common Criteria may be more important to the program manager, but that covers way more than just the Crypto. So you would probably have to have your whole VM, Image and Crypto change-set evaluated.
And... if you're going to work on a particular standard, why not work on Suite B? The NSA has been recommending the use of AES and ECC for several months now, and I believe that if you buy into Suite-B, it may be easier to get a FIPS-140 waiver.
-Cheers -Matt H.
On Jul 20, 2006, at 9:50 AM, Ron Teitelbaum wrote:
All,
The only response I received about our proposal to try to get certified was from Andreas who said he'd send it off to the Croquet board. After reading this article I really believe that we should try to get certified, if for no other reason then to help the open source community in general.
Is there still an interest in this group to go through this process? If so I will undertake the process of screening all certified labs to find the strongest lab that understands the difficulty and intricacies of open source.
Please respond back and let me know your support for the project and your willingness to participate, or any other comments.
I really think the process will be very beneficial and the challenge you have to admit is a good one.
Thanks!
-Ron Teitelbaum
Security validation of OpenSSL encryption tool uncertain Jaikumar Vijayan
July 19, 2006 (Computerworld) 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 can't 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, the Cryptographic Module Validation Program (CMVP) at the National Institute of Standards and Technology (NIST), 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 the Hattiesburg, Miss.-based Open Source Software Institute (OSSI), a nonprofit group trying to get the OpenSSL encryption module validated for use in government. John Weathersby, OSSI's executive director, today alleged that the move appears to have been influenced by vendors of proprietary technologies that 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 operating systems, including many flavors of Unix, Apple Computer Inc.'s Mac OS X and Microsoft Corp.'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 NIST in the U.S. and the Communications Security Establishment of the Canadian government.
A validated OpenSSL tool would allow vendors of operating systems, Web browsers and 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 cryptographic tools that are certified according to FIPS 140. 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," he said. 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 noncompliance 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 for Domus IT Security Laboratory, the Ottawa-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 multiyear 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 been 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 Communications Security Inc., 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 nonvalidated 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.
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Matt,
Thank you for your reply. I've been reviewing the common criteria already, but wasn't aware of it's applicability to waivers. As for the Suite B, I'm currently working on a Squeak SSL implementation. I'm starting with TLS 1.2 specifically because it uses AES. My goal in writing the TLS implementation is to get a better feeling for the components, signatures, PKI, encryption, hashing and how they work together. I've been studying the ECC and have come to the conclusion that it is necessary for anything that my company writes.
I'm not sure how much difficulty I will have with TLS 1.2, but so far it appears that we have the components necessary already and the work is moving along nicely.
As for the FIPS certification are you suggesting we continue to pursue it, or instead focus on Suite B, and the common criteria? Should we do both or one at a time in a stepwise fashion?
Thanks again for your response.
Ron Teitelbaum
-----Original Message----- From: Matthew S. Hamrick [mailto:mhamrick@cryptonomicon.net] Sent: Thursday, July 20, 2006 1:15 PM To: Ron@USMedRec.com; Cryptography Team Development List Cc: 'Andreas Raab' Subject: Re: [Cryptography Team] OpenSSL FIPS Revoked - Should we continue to try and certifiy Squeak?
Hi Ron,
Sorry for not responding to this earlier, it's been a pretty busy month for me and I'm just now getting around to catching up on email traffic.
I think I'm in a pretty good position to comment on this subject, having worked for the Department of Homeland Security, managing part of their PKI integration process. Somewhere along the line someone also put my name down as a "Federal Smartcard Program Manager." I don't know what that means, but I did do some work with Smart Cards and when I mention it to some people they seem to take it relatively seriously.
FIPS-140-2 is certainly important in the federal government. Laws exist that mandate it's use for certain federal projects. However... it's possible to get waivers for those laws. But FIPS-140-2 isn't the only certification regieme that applications and environments must adhere to. The Common Criteria are increasingly important as are adherence to the FIPS 800 series documents (though the latter are not certification processes in the commonly accepted sense.) Common Criteria covers much more than just crypto and there are Common Criteria for several aspects of system operation.
I think what I'm getting at here is, if you're trying to get a Squeak application approved for use in the US or Canadian federal governments, FIPS is important, but if the application is compelling a waiver can be received. Common Criteria may be more important to the program manager, but that covers way more than just the Crypto. So you would probably have to have your whole VM, Image and Crypto change-set evaluated.
And... if you're going to work on a particular standard, why not work on Suite B? The NSA has been recommending the use of AES and ECC for several months now, and I believe that if you buy into Suite-B, it may be easier to get a FIPS-140 waiver.
-Cheers -Matt H.
On Jul 20, 2006, at 9:50 AM, Ron Teitelbaum wrote:
All,
The only response I received about our proposal to try to get certified was from Andreas who said he'd send it off to the Croquet board. After reading this article I really believe that we should try to get certified, if for no other reason then to help the open source community in general.
Is there still an interest in this group to go through this process? If so I will undertake the process of screening all certified labs to find the strongest lab that understands the difficulty and intricacies of open source.
Please respond back and let me know your support for the project and your willingness to participate, or any other comments.
I really think the process will be very beneficial and the challenge you have to admit is a good one.
Thanks!
-Ron Teitelbaum
Security validation of OpenSSL encryption tool uncertain Jaikumar Vijayan
July 19, 2006 (Computerworld) 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 can't 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, the Cryptographic Module Validation Program (CMVP) at the National Institute of Standards and Technology (NIST), 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 the Hattiesburg, Miss.-based Open Source Software Institute (OSSI), a nonprofit group trying to get the OpenSSL encryption module validated for use in government. John Weathersby, OSSI's executive director, today alleged that the move appears to have been influenced by vendors of proprietary technologies that 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 operating systems, including many flavors of Unix, Apple Computer Inc.'s Mac OS X and Microsoft Corp.'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 NIST in the U.S. and the Communications Security Establishment of the Canadian government.
A validated OpenSSL tool would allow vendors of operating systems, Web browsers and 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 cryptographic tools that are certified according to FIPS 140. 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," he said. 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 noncompliance 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 for Domus IT Security Laboratory, the Ottawa-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 multiyear 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 been 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 Communications Security Inc., 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 nonvalidated 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.
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
cryptography@lists.squeakfoundation.org
-
Matthew S. Hamrick -
Ron Teitelbaum