In our recent post we talked about the recent changes to Common Criteria, FIPS, and DoDIN APL, and the importance of putting these changes in context for your business. Today we have another change to tell you about. On July 25, CMVP issued an update to the FIPS 140-2 Implementation Guidance(IG). No matter where your module is in the validation process, there’s information you need to know about, as this update affects you either way.
We’re going to talk about two important changes to the FIPS 140-2 IG in today’s post.
Change #1: IG 9.10 Power-Up Tests for Software Module Libraries
In FIPS, the “operator” of a software cryptographic library has been traditionally defined as the calling application to which a library links. The library will load for execution when one of its functions is invoked. Many open source-based cryptographic libraries require that the initial invocation be to a function that performs the required power-up self-tests, and this behavior was acceptable… until now.
CMVP has issued guidance that states that these cryptographic libraries can no longer rely on the calling application to make a specific function call that invokes the tests at power-up because this behavior fails the requirement that self-test execution at power-up be automatic, without requiring operator intervention. FIPS now requires that libraries include a code segment called a “default entry point” that automatically executes when the library is loaded, regardless of what function is initially invoked by the calling application. In addition, this code segment must perform the power-up self-tests.
What’s important here is that this IG update is effective immediately, and that it applies to modules that were submitted to the lab − and even to those already in the CMVP queue− prior to the IG update’s July 25 release. This update impacts every candidate software library validation that has not yet reached Coordination.
How does this affect you? Your library will probably need modification to include this DEP. How you design this feature is up to you; provided it meets the requirement of automatic execution of power-up self-tests upon library load/link. The IG does include “examples” here of how a DEP might be defined.
Change #2: IG D.11 References to the Support of Industry Protocols
Although FIPS 140-2 doesn’t address protocols, it does address many of the underlying algorithms and schemes that provide support to a given protocol. And, because these algorithms (including encryption/decryption, hashing, and key derivation) and schemes (including key agreement) are under FIPS purview, they must be validated through the Cryptographic Algorithm Validation Program(CAVP) in order for them to be part of a cryptographic module in an Approved mode of operation.
The FIPS validation now requires algorithm testing on key derivation functions (KDFs) if the module claims to implement any of the following protocols in an Approved mode of operation. You can find more information in NIST SP 800-135 rev 1:
- American National Standard (ANS) X9.42-2001-Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography (ANS X9.42-2001) [ANS X9.42] (also in RFC 2631 [RFC 2631])
- American National Standard (ANS) X9.63-2001-Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography (ANS X9.63-2001) [ANS X9.63] (also in RFC 3278 [RFC 3278])
- Internet Key Exchange (IKE) (version 1: RFC 2409 [RFC 2409] and version 2: RFC 4306 [RFC 4306])
- Secure Shell (SSH): RFC 4251 [RFC 4251]
- Transport Layer Security (TLS) version 1.0: RFC 2246 [RFC 2246], version 1.1: RFC 4346 [RFC 4346] and version 1.2: RFC 5246 [RFC 5246]
- The Secure Real-time Transport Protocol (SRTP): RFC 3711 [RFC 3711]
- User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMP): RFC 2574 [RFC 2574]
- Trusted Platform Module (TPM) (Parts 1 [TPM Principles], 2 [TPM Structures] and 3 [TPM Commands])
If KDF testing is not performed, then the KDF must be listed as “non-compliant” in your documentation, and the module’s Security Policy must include a caveat that states that the associated protocol(s) cannot be used in an Approved mode of operation.
This update applies to you if your candidate module is in the test lab now but has not yet been submitted to CMVP. If the module has already been submitted to CMVP, it will be validated under the previous rule.
If you have not yet submitted your modules, take note! You’ll be required to comply with the new guidance. Not every instance of this new change has been made clear as of this writing. For example, Corsec is in the process of determining the requirements for KDF testing on modules that use Open-SSL-based crypto engines, but we do know that similar efforts will be necessary for other open source-based libraries and other vendor-specific implementations.
If you’re uncertain how all the recent IG changes might affect your FIPS validation, or would like additional details about the new FIPS 140-2 IG, let us know. We’ll be happy to help.