OpenSSL and ACVP Parsing

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.

Update 2019-Oct-23: NIST provided a new timeline for the sunsetting of CAVS. The CAVS retirement date is 30 June 2020. No algorithm validations will be issued for CAVS test results submitted after this date. Starting 1 July 2020, ACVTS will be the only means of doing so.

In addition to the updated guidance from NIST, be aware that starting January 1, 2020, only labs with ACVP production credentials can continue to perform CAVS validations for vendors. Lightship has production credentials and therefore we can continue to perform CAVS validations up until June 30, 2020.

If you are not yet aware, the current NIST cryptographic algorithm testing platform (CAVS) is now end-of-support with end-of-life slated for June 30, 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. It is unclear if and when OpenSSL 3.0 will contain an appropriate ACVP test harness. At the International Cryptographic Module Conference 2019, we were told this might happen shortly after OpenSSL 3.0 is released, but we’ve heard no news since then.

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 are 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 addition, ACVP may introduce new test cases which are not currently handled in the CAVS format potentially leaving a hole in how test harnesses can complete algorithm validations.

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 OpenSSL 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

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

The goals in providing the our 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.

 

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.