OpenSSL and ACVP Parsing

Greg McLearn ACVP, FIPS 140-2

OpenSSL is used in some part by an overwhelmingly large percentage of the enterprise vendor community. Those vendors which need to go through FIPS 140-2 or Common Criteria may find themselves needing to perform algorithm testing and may be presented with only being able to interact with the new ACVP-formatted test cases. Below, we talk about some practical options available to those vendors who have not yet bridged the gap.

If you are not yet aware, the current NIST cryptographic algorithm testing platform (CAVS) is now end-of-support with end-of-life slated at the end of 2020. In its place, NIST has constructed a promising new automated cryptographic processing system called ACVP.

A big question for the industry is when OpenSSL will get support for ACVP. Officially, it will only be supported when the new OpenSSL 3.0 FIPS source code has been finalized which could still be quite some time out.

For vendors who are looking to start working with the ACVP system sooner rather than later or to continue to leverage the older OpenSSL 2.0 FIPS canister code, there are basically two reasonable options. (We are ignoring the rather significant issue of actually communicating with the ACVP service, though that becomes a concern primarily for labs rather than vendors since a majority of vendors will not have direct access to the NIST service.)

  1. Construct an ACVP to CAVS (and vice-versa) translator. With this, a lab can provide a vendor with an ACVP JSON formatted test request. A translator would convert the modern JSON test cases back to the legacy CAVS formats which the OpenSSL test engine can continue to consume.
  2. Build an ACVP parsing engine into the existing OpenSSL FIPS test framework. This embraces the modern approach and acts as a stopgap until the official OpenSSL FIPS ACVP test framework is ready.

Lightship has experimented with both of these approaches.

The CAVS translator, while appealing in theory, has significant drawbacks and technical challenges. The largest drawback is that CAVS is no longer being updated. NIST is eventually going to be mandating algorithms and components which CAVS will not be able to provide vectors for.

From a technical perspective, the translation effort from ACVP to CAVS becomes a problem in how to re-group test cases. Legacy CAVS formatted tests have highly disparate formats. For example, AES test vectors is split into 5-6 different files per tested key size, whereas HMAC test vectors are combined into a single file. By contrast ACVP are uniformly structured as a series of test cases within a series of test groups. A test group is a logical collection of test cases that might exercise a certain property or behaviour. OpenSSL — and likely any vendor-derivations — is sensitive to unstructured text information in the legacy CAVS header as well as the file name. Therefore reconstituting these components is very challenging.

In our view, while initially appealing, a CAVS to ACVP translation service has a limited shelf-life and a potentially high development cost. Lightship’s development group experimented with such a translator tool and has put the code, in all of its experimental glory, on our Github site.

The second approach — parsing ACVP natively within OpenSSL’s 2.0.16 FOM — has so far seemed easier to manage. A vendor who relies on the OpenSSL test framework can ingest modern ACVP JSON and emit JSON responses. The responsibility of communicating with the NIST service is likely still going to be the responsibility of the lab, however.

Adding ACVP support to the OpenSSL FIPS test framework has some of its own unique challenges. Primarily these are related to the fact that those test harnesses were built over different times and possibly by different people. The styles and harness designs differ. However, we’ve essentially boiled it down to the following pattern:

Parse the JSON input
Initialize an output JSON tree
For each test group in the testGroups:
    For each test case in the tests:
        Execute the same OpenSSL FIPS 2.0.16 algorithm with the same inputs
        Output result node

The goals in providing the ACVP parsing engine within the OpenSSL test framework were:

  • Leverage existing, known-good testing harnesses and supplement them with new JSON parsing
  • Keep CAVS parsing and execution unaffected.
  • Use lightweight JSON parsing with licensing compatible with OpenSSL.
  • Provide working proofs-of-concept for vendors to examine as they navigate the new AVCP process.

Our experimental code is available on our Github site and is provided as-is.

Talk to us today to learn more about ACVP and Lightship’s algorithm testing roadmap and help certify your product at the speed of development.