Thursday, September 26, 2013

ICMC: Reuse of Validation of Other Third Party Components in a 140-2 Cryptographic Module

Presented: Jonathan Smith, Senior Cryptographic Equipment Assessment Laboratory (CEAL) Tester, CygnaCom Solutions

What is component in this context?  An algorithm, 140-2 module, third party library, etc - not a hardware device.  There is more interest in this area, as more validations are occurring.  Requirements are not obvious in this area, and there isn't a lot of guidance to follow.

Let's say you want to reuse an algorithm that has its CAVP certificates - if you wan to leverage that validation, you have to make sure you are talking about the same Operational Environment (OS/processor for software) and that there is no change within the algorithm boundary when you embed it within a module.  CAVP boundaries are not as well defined as CMVP, but for all intents and purpose it is the compiled binary executable that contains the algorithm implementation.

When you're reusing someone else's algorithm, you will have a hard time to make sure all of the CMVP self-tests are all being run at the right time. You may not be able to reuse it with out rebuilding it.

Now you may want to use an entire validated module - first make sure you have the correct validated version.  If you can use it completely unchanged, you will have to reference the other module's certificate.  One note, if the embedded module is Level 2, but your code only meets Level 1 criteria - the composite module could not be evaluated higher than Level 1. Now, the inverse is not necessarily true - you might be embedding a Level 1 module, but your different use cases may allow you to get a higher level for the composite module.

To reuse this module, again, you need to have an unchanged operational environment the same as trying to reuse an algorithm.  The new module boundary must include the entire boundary of the included module. You'll need to have a consistent error state - you cannot allow one part of the composite module to enter an error state while the rest of the system continues serving crypto.

Your documentation can quite frequently reference the embedded module's documentation, leaving certain tasks up to the embedded module.  Make sure the new capabilities of the composite module are documented.

A question came up about using multiple vendor's modules together, where they each have their own validation certificate.  Mr. Easter (CMVP) recommended we read Implementation Guidance (IG) 7.7 for detailed advice on this concept.

There was a question about if the embedded module was validated before new IG came out - what then?  As long as the embedded module meets SP800-31A, then the old certificate fully applies and you will not have to bring it up to the new IG.

This post syndicated from: Thoughts on security, beer, theater and biking!