The Role of Cryptographic Algorithm Validations in Common Criteria (CAVP FAQ)

[Updated July 6, 2021 – NIAP requires exact match CPU specs in CAVP certificates]

Most CC evaluations performed in North America include cryptographic security claims called out in the target Protection Profile (PP) that is being used.  Those requirements are met by obtaining validation certificates from the Cryptographic Algorithm Program (CAVP).  The CAVP is a subset of the broader Cryptographic Module Validation Program (CMVP) that validates entire crypto modules against the FIPS 140-2/3 standard (ISO19790).

This post will explore the intersection between CC and FIPS 140 (in North America) and how the CAVP plays a key role in the eventual CC certification of a given product.

Full CMVP module validation is not typically required specifically for CC (except some edge cases for EAL evaluations in Canada),  but may be required as a separate validation by other procurement policies (particularly US and Canadian federal agencies).   

The cryptographic algorithms that a module implements are validated under the CAVP.  It is these CAVP certificates that are required for CC certification.  The specifics depend on whether you are conforming to a PP or EAL. This post will focus on Protection Profiles and NIAP’s (US CC Scheme) related requirements per Policy #005.

A CAVP certificate consists of the following critical elements:

• Implementation Name. A name that the vendor assigns.
• Version. A version that the vendor assigns. This need not bear any relationship to the version of the product undergoing CC evaluation – it’s better if it doesn’t (so that the CAVP certificate survives non crypto related product version changes).
• Operating Environment (OE). The specific hardware down to the processor microarchitecture and software (OS) environment used for testing.
• Algorithm Capabilities. The algorithm details that were tested (e.g. algorithm, mode, key size etc., AES-CBC-256).

All of these elements are important to get right to ensure a successful CC certification. The Implementation Name and Version are only important insofar as being able to show the Target of Evaluation (TOE) actually does use the tested implementation – this can be tricky. You should have some record (e.g. configuration management system record) that shows that ‘My Great Module v1.0’ == xyz.dll. The Operating Environment and Algorithm Capabilities must exactly match the details specified in the Security Target.  It is also worth noting that only NIST approved crypto can be tested and validated under the program.  Bespoke algorithms or non-standard implementations cannot be validated or claimed for the purposes of CC certification.

Operating Environment Requirements

NIAP requires that the OE be specified down to the exact CPU, including the OS and any hypervisor.  If anyone can point to an example of when a software crypto algorithm magically broke because of a different CPU microarchitecture, we’d like to hear about it…

The key takeaway is, at the end of your CC evaluation, the OE in the CAVP cert needs to exactly match the environment specified in the Security Target (i.e. OS -> Hypervisor (if any) -> CPU), including whether acceleration is used (e.g. Intel AES-NI). This gets complicated quickly when multiple hardware appliances are in play.  Lightship’s recommendation in this scenario is to pick one model as the tested configuration, and list other models as supported.

Frequently Asked Questions for NIAP Policy #5 does a good job of explaining these requirements as another reference point.

Algorithm Capability Requirements

The required capabilities all depend on the crypto that is in scope for the CC evaluation – that is, per the ‘FCS’ functional requirements included in the Security Target. These ‘FCS’ requirements are in turn driven by options/selections made elsewhere (depending on the Protection Profile):

• Protocol selections (e.g. TLS ciphersuites, SSH configuration, IPSec etc.)
• Trusted update selections (e.g. digital signature algorithms)
• Other Protection Profile dependant crypto related selections

NIAP have published a CAVP Mapping between FCS requirements and CAVP.

Typical Algorithm Capabilities for the ubiquitous Network Devices collaborative Protection Profile (NDcPP)

A typical set of NDcPP CAVP capabilities would be something like:

• RSA Key Gen (186-4)
• RSA Sig Gen / Sig Ver (186-4)
• ECDSA Key Gen (186-4)
• ECDSA Sig Gen / Sig Ver (186-4)
• DSA Key Gen (186-4)
• AES-CBC, AES-CTR, AES-GCM
• SHA-1, SHA-256, SHA-384, SHA-512
• HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512
• KAS-ECC Component  (not CDH-Component), preferably SP800-56Ar3
• KAS-FFC Component (not CDH-Component), preferably SP800-56Ar3
• DRBG (Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES))

Gotchas

Issues that seem to come up often:

• RSA FIPS186-4. It is common for CAVP certificates to include RSA 186-2 which has now be superseded by 186-4. You can avoid by excluding RSA from scope (e.g. not claiming RSA ciphers or signatures), or ensuring CAVP coverage.
• KAS-ECC Component. Required for EC Diffie Helman (TLS_ECDHE), it is common for CAVP certificates to include KAS-ECC-CDH Component.  The CDH caveat is not acceptable per NIAP.  You can avoid this issued by not claiming EC DH or ensuring CAVP coverage.
• Missing Detail in OEs. If the OE in the CAVP certificate is not precise enough (e.g. CentOS on Intel Xeon vs CentOS 11.2 on Intel Xeon Gold 5510), then this will cause issues.
• ACVP. The recent transition to the Automated Cryptographic Validation Program (ACVP) has been an issue for many vendors because the most widely used crypto modules (like OpenSSL) do not yet have open-source test harnesses that are required for obtaining new CAVP certificates or updating old ones.

In summary, getting CAVP right is critical to a successful Common Criteria certification.  Be sure to address this aspect early in your certification project – a little effort early on can help avoid costly delays later on.

Lightship Security is the fastest growing CC and CMVP laboratory in North America. Reach out to see how our testing experts have helped many of the leading product vendors in the world with their product certification needs and why we can do the same for you.

---