Welcome to the Acumen Security Blog

CMUF update from the CMVP

Hi Everyone,

Some important updates the recent Cryptographic Module User Forum (CMUF) Meeting for March 2017. The joint CMVP leads Jennifer Cawthra (NIST) and Carolyn French (CSE) shared some important updates to the Implementation Under Test (IUT) and Modules In Process Listing (MIP) processes. They also discussed the recent move of modules to the Historical listing website and shared a new definition for a 2SUB. Please find details on each of these topics below:

IUTB and the MIP list:

  • The module review process begins once NIST confirm the Cost Recovery fee for the submission has been paid. To expedite this process labs can request an invoice from NIST before a module report is submitted.
  • If >90 days after IUTB the report has not been submitted – NIST will remove it from the IUT listing.
    When NIST receive the module report and see the invoice is paid module will return to its place in the queue and is added to the MIP list.

As of July 1st, 2017:

  • Stagnant modules in IUT will be dropped after 18 months on the list.
  • CMVP comments have been sent to the lab + 90 days without a response. Module put On Hold and removed from MIP list. Once comments are received module goes back on MIP list and returns to its place on queue.

As of January 1st, 2018:

  • All certifications must be completed within 2 years of report submission or IUTB request, whichever occurred first
  • At 2-year submission anniversary, module will be dropped from MIP list.
  • Vendor and lab will need to re-start the validation process from the beginning including paying a new NIST Cost Recovery Fee
  • This policy will be affect all new submissions and submissions in the queue as of 01/01/2018
  • Labs have been (and will be) notified of modules that will be dropped as of 01/01/2018

CMVP Historical Listing:

  • As of February 1st, 2017, modules validated to FIPS 140-1 and modules validated over 5 years ago have been moved to the Historical Listing.
  • 575 certificates were moved to the Historical Listing
  • These modules are not to be used for procurement by Federal Agencies.
  • If these modules are already being used, Federal Agencies makes a risk-based decision on whether to continue using them or to replace them.
  • 1SUBs where the module is unchanged will not move a module from the historical list back to the active validation list
  • 3SUBs will be accepted for up to 2 years after the modules sunset date. The resulting new certificate will appear on the active validation list.

New 2SUB definition

  • As of May 2017, IG G.8 will be updated to have a new definition for a 2SUB. It will be for extending the module’s certificate sunset date.
  • Module must meet all the latest standards/FIPS requirements/IGs and CAVP testing requirements at the time of 2SUB submission.
  • Only available to modules on the active validation list.
  • IG G.8 sent to public for comments – comments due April 14th, 2017. Ping Acumen if you would like the draft IG for review.

RSA Key Generation and Common Criteria

Hi all! Does your application or HW product being considered for CC validation use the validated OpenSSL FOM for crypto? If so, you should pay close attention to a recent Technical Decision issued by NIAP (TD107). As many of you know, the open source validated version of the OpenSSL supports FIPS 186-2 Key Generation and not the more recent standard revision (FIPS 186-4). It is this functionality that the TD addresses. The following is an excerpt,

The referenced protection profiles (PPs) allow for the generation of asymmetric keys using RSA schemes that meet FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3. or ANSI X9.31-1998, Section 4.1.

Up until this point many of the Protection Profiles have allowed for FIPS 186-4 Key Generation or ANSI X9.31 Key Generation (with the caveat that the older PRNG listed in ANSI X9.31 is not used for randomness). This is allowance is included in several PPs which are commonly evaluated against, including, Application Software PP, Mobile Device PP, OS PP, VP Client PP, and VoIP PP.

The TD goes on to modify the Key Generation requirement, as follows,

Effective immediately, RSA schemes using ANSI X9.31-1998, Section 4.1 is no longer a valid selection. NIAP will not accept products into evaluation that claim RSA schemes that meet ANSI X9.31-1998 Section 4.1

While for typical network devices being evaluated against the NDcPP this has been a hard requirement for some time, this is essentially a new requirement for software applications planning to go through certification. It is no longer possible to use the stock validated OpenSSL FOM to meet the crypto requirements in the PPs listed above.

Now there are several lightweight modifications you can make to the OpenSSL FOM code bring it into conformance with FIPS 186-4, however, as you likely know it will invalidate the previous FIPS certification for the OpenSSL module. I anticipate that this will be a problem for vendors hoping to meet their FIPS validated cryptography requirements leveraging the embedded OpenSSL module and going against any of these PP.

Please do keep this in mind when considering your upcoming certification efforts. As always, if you have any questions please give me a call or send me an email. I love to talk 