December 8, 2015
UL Acquires InfoGard to Broaden Company’s Range of Security Services
UL has acquired InfoGard, a market leader in accredited security assurance services for the payment sector and federally mandated IT secure products, and positions UL in the healthcare IT and biometric secure authentication sectors. Learn more at:
November 12, 2015
CMVP Adopts 5-year Validation Sunsetting Policy and an RNG Transition Update
Following the annual lab managers meeting and International Crypto Module Conference (ICMC) last week, the CMVP has released a few important notices that have a large impact on the community at large.
The first describes a new policy in which FIPS validation certificates older than 5 years will be moved to a "Legacy Validation List". The Legacy Validation list is not to be used for procurement by federal agencies. This policy becomes effective January 1st, 2017.
This new policy will certainly have a large impact on our government agencies who will potentially be in violation of FISMA when this policy takes affect. In a way this is a good thing, though. It keeps dated technology not up to current security guidelines from protecting sensitive information within our government.
For product vendors, there is a process to keep older modules off of this legacy list, but it does involve working with the labs to demonstrate that the module is compliant with all current standards and implementation guidance. This work would need to take place prior to January 1, 2017. I suggest that you begin this work now. In some cases, depending on when the module was validated, it may be a large undertaking to demonstrate that all current guidance is being adhered to.
The second notice of interest relates to the RNG transition. We know that RNG's will no longer be considered Approved for key generation at the end of this year. Any module that has an RNG will be moved to the same Legacy Validation List described above. The CMVP has allowed for updating these modules through a 1SUB like process ("bug fix" or "maintenance letter" process). This will allow for an efficient and timely process for keeping these modules off of the legacy list.
Here is the link to the notices (again):
http://csrc.nist.gov/groups/STM/cmvp/notices.html
The first describes a new policy in which FIPS validation certificates older than 5 years will be moved to a "Legacy Validation List". The Legacy Validation list is not to be used for procurement by federal agencies. This policy becomes effective January 1st, 2017.
This new policy will certainly have a large impact on our government agencies who will potentially be in violation of FISMA when this policy takes affect. In a way this is a good thing, though. It keeps dated technology not up to current security guidelines from protecting sensitive information within our government.
For product vendors, there is a process to keep older modules off of this legacy list, but it does involve working with the labs to demonstrate that the module is compliant with all current standards and implementation guidance. This work would need to take place prior to January 1, 2017. I suggest that you begin this work now. In some cases, depending on when the module was validated, it may be a large undertaking to demonstrate that all current guidance is being adhered to.
The second notice of interest relates to the RNG transition. We know that RNG's will no longer be considered Approved for key generation at the end of this year. Any module that has an RNG will be moved to the same Legacy Validation List described above. The CMVP has allowed for updating these modules through a 1SUB like process ("bug fix" or "maintenance letter" process). This will allow for an efficient and timely process for keeping these modules off of the legacy list.
Here is the link to the notices (again):
http://csrc.nist.gov/groups/STM/cmvp/notices.html
August 12, 2015
NIST Seeking Public Comments on ISO/IEC 19790:2012
NIST announced today that they are seeking public comments
on using ISO/IEC standards for cryptographic
algorithm and cryptographic module testing, conformance, and validation
activities, currently specified by Federal Information Processing Standard (FIPS) 140-2.
The responses to this request will be used to plan possible changes to the FIPS standard or in a decision to use all or part of ISO/IEC 19790:2012, Security Requirements for Cryptographic Modules, for testing, conformance and validation of cryptographic algorithms and modules.
The comment period is 45 days (September 28, 2015) and all are encouraged to provide feedback. Seeing as though the next revision of the FIPS standard is long overdue, the hope is that the comments that are provided help NIST converge on a solution. Even if not all aspects of the current ISO standard are perfect, it is still a big improvement compared to continuing to test to FIPS 140-2.
The responses to this request will be used to plan possible changes to the FIPS standard or in a decision to use all or part of ISO/IEC 19790:2012, Security Requirements for Cryptographic Modules, for testing, conformance and validation of cryptographic algorithms and modules.
The comment period is 45 days (September 28, 2015) and all are encouraged to provide feedback. Seeing as though the next revision of the FIPS standard is long overdue, the hope is that the comments that are provided help NIST converge on a solution. Even if not all aspects of the current ISO standard are perfect, it is still a big improvement compared to continuing to test to FIPS 140-2.
May 29, 2015
Urgent: CMVP Guidance Effective Immediately
This morning, the CMVP released a notice to all labs acknowledging that not all SP 800-90A DRBG implementations submitted for validation have been entirely compliant with the SP 800-90A standard.
Specifically, Section 11.3 of the standard requires that certain health checks be performed. It was not always clear that these health checks were required for CMVP validation. In fact, based on some interpretations, wording within SP800-90A itself would leave some to believe that they were, indeed, not required.
The CMVP's stance, based on guidance from the Cryptographic Technology Group, is now that these health checks are absolutely required in order to claim that a DRBG implementation is compliant to 800-90. This guidance is effective IMMEDIATELY, and even impacts modules that are currently in the queue and in the Coordination phase.
For reports currently in the queue where the module does not implement a compliant DRBG, the lab is to notify the CMVP to put the submission on HOLD until the DRBG implementation comes into compliance and is tested by the lab.
(UPDATE as of 6/1/15 - For reports in the queue where the module does NOT implement the health checks, the lab is still to notify the CMVP to place the report on HOLD, but there are two options for moving forward. One, is to bring the module into compliance and resubmit the report with all appropriate test evidence. Or two, is to rework the validation documentation and report to show the DRBG implementation as Non-Compliant. This would include identifying all services within the SP and report that utilize the non-compliant DRBG. The lab can resubmit the reworked SP and report to the CMVP and the validation will proceed accordingly).
If your particular module is impacted by this, make the appropriate changes now and work with your lab to have them tested (i.e. operational tested and/or code reviewed).
Specifically, Section 11.3 of the standard requires that certain health checks be performed. It was not always clear that these health checks were required for CMVP validation. In fact, based on some interpretations, wording within SP800-90A itself would leave some to believe that they were, indeed, not required.
The CMVP's stance, based on guidance from the Cryptographic Technology Group, is now that these health checks are absolutely required in order to claim that a DRBG implementation is compliant to 800-90. This guidance is effective IMMEDIATELY, and even impacts modules that are currently in the queue and in the Coordination phase.
For reports currently in the queue where the module does not implement a compliant DRBG, the lab is to notify the CMVP to put the submission on HOLD until the DRBG implementation comes into compliance and is tested by the lab.
(UPDATE as of 6/1/15 - For reports in the queue where the module does NOT implement the health checks, the lab is still to notify the CMVP to place the report on HOLD, but there are two options for moving forward. One, is to bring the module into compliance and resubmit the report with all appropriate test evidence. Or two, is to rework the validation documentation and report to show the DRBG implementation as Non-Compliant. This would include identifying all services within the SP and report that utilize the non-compliant DRBG. The lab can resubmit the reworked SP and report to the CMVP and the validation will proceed accordingly).
If your particular module is impacted by this, make the appropriate changes now and work with your lab to have them tested (i.e. operational tested and/or code reviewed).
April 16, 2015
InfoGard at RSA 2015
InfoGard Laboratories will be exhibiting at the 2015 RSA Conference in San Francisco, CA April 20-23, 2015.
Please visit us at Booth #312 (South Expo).
Please visit us at Booth #312 (South Expo).
January 6, 2015
Record number of FIPS 140-2 certificates issued in 2014
In 2014, The CMVP validated the most FIPS 140-2 cryptographic modules in a given year in the history of the program. 233 new FIPS
certificates were issued last year, which surpassed the previous high of 229 in 2010.
Here are the totals by Laboratory for 2014:
Congratulations to the FIPS Team at InfoGard Laboratories. That's 6 years in a row of producing the most FIPS 140-2 certificates (2009-2014).
Here are the totals by Laboratory for 2014:
Congratulations to the FIPS Team at InfoGard Laboratories. That's 6 years in a row of producing the most FIPS 140-2 certificates (2009-2014).
Subscribe to:
Posts (Atom)