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.

New Guidance from the CMVP on Operational Environment (OE) requirements

Here at Acumen we want to keep our clients plugged-in as product certification requirements change or evolve. From time to time FIPS 140-2 testing labs receive updates or new guidance from the Cryptographic Module Validation Program (CMVP). The following guidance was sent from CMVP last week pertaining to the level of detail required for cryptographic module operational environments for CAVP algorithm validation certificates and FIPS 140-2 module validation certificates (under the CMVP). The CMVP emphasized that the information in the OE field must be accurate and adhere to CAVP FAQ GEN.12. Specifically:

1. The information listed in the OE field is a valid operating system (or operating system family) and/or processor (or processor family). Note: There have been cases where the information supplied for the OE was a platform and not a valid operating system and/or processor. Simply listing the platform is not allowed for CAVS validations.

2. The information listed in this field is the operating system (or operating system family) and/or processor (or processor family) on which the CAVP algorithm validation testing was performed and on which the response results were produced.

GEN.12 in the CAVP FAQ (http://csrc.nist.gov/groups/STM/cavp/documents/CAVPFAQ.pdf) defines Operating System Family and Process Family as follows:

“For Software implementations, the following information must be listed:

1. Processor – This field shall identify the vendor and processor family. Examples that satisfy the requirement for the processor field are Intel Core i5, ARM 7, and AMD Opteron.

No further specificity is required unless the vendor or the lab knows that the software implementation executes differently on different processors within the same family. In this case, the listing must be more specific. AES.2 describes such a case. A vendor may also choose to be more specific than
required, e.g., in order to gain a marketing benefit.

2. Operating system – This field shall identify the vendor and operating system family, or major version number where more appropriate. Examples that
satisfy the requirement for the OS field are Microsoft Windows Vista, Apple Mac OS X, Red Hat Enterprise Linux 5, and Wind River VxWorks 6.
No further specificity is required unless the vendor or lab knows that the software implementation executes differently on different OSes within the
same OS family or major version number. In this case, the listing must be more specific. A vendor may also choose to be more specific than required if
so desired. Any virtual machine (VM) used during testing shall be listed in the OS field of the Operating Environment (OE). If the VM was running between the software implementation and the OS, as in the case of a Java VM, it should be listed along with the OS using the same vendor and family/version number requirements. See GEN.17 for the case of a VM running underneath the target OS.

From a CAVP algorithm validation perspective, the OE field can either list the actual operating system and/or processor or it can list the operating system family and/or processor family, or some combination thereof.

On a FIPS 140-2 validation certificate (under the CMVP), the OE must consist of the actual operating system and platform (with processor if applicable).

– If the CAVP validation lists the actual OEs operating system and/or processor, then the CMVP OEs operating system must match and/or processor must match.

– If the CAVP validation lists an operating system family, then the actual operating system listed on theFIPS 140-2 certificate must be a member of the operating system family. Likewise, if the CAVP validation lists a processor family, then the processor of the actual platform listed on the FIPS 140-2 certificate must be a member of that processor family. The OE components in both the CAVP validation and the CMVP certificate must be in sync.

If the CAVP algorithm validation indicates an OE consisting of a processor family and/or an operating system family and the CMVP module validation indicates a processor and/or an operating system that is a member of the corresponding families, the lab must provide an explanation/rationale of how the CMVP OE satisfies CAVP FAQ GEN.10 and GEN.12, and CMVP IG 1.4. (For example, the CAVP validation might list Intel Xeon and then the CMVP test report might list Intel Xeon E5-4603 v2 and Intel Xeon E7-8893 v4. The lab would provide an explanation/rationale to address the difference.)

FIPS 140-2 IG G.13 (http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf) states the following:

the specific operational environment(s) or configuration(s) that was employed during testing by the CST laboratory shall be specified for all module types. (e.g. software, firmware, hardware and hybrid). This shall match the information in the test report in AS.01.08. The operational environment includes both the operating system(s) and the tested platform(s).

Therefore, if the tested platform itself may be procured with different processors, the processor on which the module was tested shall be listed on the CMVP certificate, security policy and test report.

Even with this recent clarification we understand if you might still have questions or concerns on how this applies to you. Please dont hesitate to contact us if we can be of assistance – we would be happy to walk through these requirements in the context of your cryptographic module or products.