Welcome to the Acumen Security Blog

Archives for September 2016

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.

/rt

NIST Cost Recovery increase October 1st

Hi Everyone – Ryan from Acumen here. We wanted to remind everyone that the new NIST Cost Recovery fees for FIPS 140-2 module submissions will be in effect as of October 1st, 2017. This means if your module validation report is submitted to the CMVP on or after October 1, 2016 (ET), the cost recovery fee will be the FY17 cost recovery rates.

The FY17 rates are as follows:

IG G.8 Scenario’s 1, 2 and 4: CR fee N/A, ECR fee: $1000
IG G.8 scenario’s 1A and 1B: CR fee $1500, ECR fee: $1000
IG G.8 Scenario 3: CR fee $3000, ECR fee: $1500
IG G.8 Scenario 5:
Security Level 1: CR fee: $6000, ECR fee: $3000
Security Level 2: CR fee: $8000, ECR fee: $4000
Security Level 3: CR fee: $11000, ECR fee: $5000
Security Level 4: CR fee: $15000, ECR fee: $6000

If your module validation report is submitted to the CMVP between September 22 and 30, 2016 (ET), the cost recovery fee will be the FY16 (current) cost recovery rate.

As a result of the transition to a new fiscal year NIST Billing will also be unavailable from Thursday September 22nd, 2016 to Monday, October 3, 2016.

Please see the CMVP website (http://csrc.nist.gov/groups/STM/cmvp/notices.html) or the CMVP FAQ for additional information on Cost Recovery fees levied by NIST for FIPS 140-2 submissions or feel free to reach out to the Acumen team if you have questions on how or if your module submission will be affected by the NIST FY17 transition.