Welcome to the Acumen Security Blog

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 

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