Cryptographic Module Validation Program CMVP

Caveats

A module validation caveat may warn a user of specific stipulations, conditions, or limitations of a module, to assist in making a risk determination on its usage.

The examples below list the potential caveats for a FIPS 140-3 validation (for a list of FIPS 140-2 caveats, see Implementation Guidance G.13 #4). A caveat may be added, modified or expanded by the CMVP during the validation process.

Mode of Operation Caveats

• <no caveat>
  • The module can only be installed and operated in an approved mode of operation.
• When operated in approved mode
  • The module can be installed or operated in either an approved or non-approved mode of operation. In order for the module to achieve the security objectives of the FIPS 140-3 standard (i.e., ISO/IEC 19790:2012 Section 6), the module must be in an approved mode of operation as specified in the module's Security Policy.
• When installed, initialized and configured as specified in Section [section number] of the Security Policy
  • The module can be installed, initialized and/or configured in order to be considered a FIPS 140-3 recognized module. Without this configuration, the module is not considered a FIPS-validated module. After this configuration, a module may run in approved mode or non-approved mode (if supported) which may require additional configuration and/or procedural guidance to invoke.
• The <tamper evident seals> and <security devices> installed as indicated in the Security Policy
  • Installation of the referenced components required for the module to operate in an approved mode of operation.
• When operated in approved mode and initialized to overall level 2 per Security Policy
  • The module can be initialized to operate at different overall levels.  E.g., A module can be initialized to either support level 2 role-based authentication or initialized to support only level 3 identity based authentication.

Bound/Embedded Module Caveats

• When operated in approved mode with module [module name] validated to FIPS 140-3 under Cert. #xxxx operating in approved mode
  • The module’s validation is bound to another validated cryptographic module.  E.g., A software cryptographic module which requires services from another validated software cryptographic module operating in the same operational environment. Application services are available from either module.
• This module contains the embedded module [module name] validated to FIPS 140-3 under Cert. #xxxx operating in approved mode
  • If the module incorporates an embedded validated cryptographic module.
  • Example 1: a software cryptographic module which is compiled with a privately linked validated software cryptographic module operating in the same operational environment. Application services are only available from the module indicated on the certificate. 
  • Example 2: A hardware cryptographic module which has embedded within its physical boundary a validated cryptographic module.

Key/Entropy Caveats

• The module generates SSPs (e.g., keys) whose strengths are modified by available entropy
  • Entropy used to generate the module’s SSPs is at least 112 bits while the module generates SSPs with a comparable cryptographic strength greater than the amount of available entropy.  Please refer to IG 9.3.A.
• The module generates random strings whose strengths are modified by available entropy
  • The module generates random strings that are not SSPs, and the security strength of a generated string is less than the bit length of the string due to limited entropy.  Please refer to IG 9.3.A.
• The module generates SSPs (e.g., keys) and random strings whose strengths are modified by available entropy
  • The module generates both SSPs and random strings that are not SSPs that have security strengths less than the presumed strengths of the SSPs and strings. Please refer to IG 9.3.A.
• No assurance of the minimum strength of generated SSPs (e.g., keys)
  • The entropy seed is obtained from outside of the module’s boundary with no CMVP evaluation on the entropy.  Please refer to IG 9.3.A.
• When entropy is externally loaded, no assurance of the minimum strength of generated SSPs (e.g., keys)
  • Entropy source falls under a particular condition specified in IG 9.3.A scenario 3. 
• No assurance of minimum security of SSPs (e.g., keys, bit strings) that are externally loaded, or of SSPs established with externally loaded SSPs
  • The module receives SSPs (e.g., keys or bit strings) from outside of its boundary for use within an approved algorithm (e.g., a key used for AES encryption; or a bit string used for generating the k values of DSA and ECDSA sigGen algorithms).  This caveat does not apply to a seed used for an internal DRBG, or a seed used in an asymmetric key generation algorithm since that must be obtained from an approved DRBG in compliance with SP 800-133r2.
• The output of the DRBG may not be used to generate SSPs (e.g., keys)
  • The module implements a DRBG and the underlying entropy source does not meet the requirements of IGs 9.3.A, D.J and D.K.

Other Caveats

• No operator authentication is enforced for executing security services that were unlocked by an authenticated service
  • Used by modules implementing and claiming role-based authentication (ISO/IEC 19790:2012 Section 7.4 at Level 2) for most services but where some security services that require authentication rely on other authenticated services to unlock them for use rather than implementing their own operator authentication verification. This is considered a lock-based authentication model where controlled or trusted operator(s) access is assumed outside the module, as described in the Security Policy, while security services are unlocked and can be executed by any operator. Please refer to IG 4.1.A Additional Comment #8.
• When utilizing a Trusted Channel as specified in the Security Policy
  • If the use of the Trusted Channel is claimed to meet the FIPS 140-3 compliance requirements of ISO/IEC 19790:2012 Section 7.3.4. Please refer to IGs 3.4.A and 9.5.A.
• The protocol(s) <TLS, SSH, …> shall not be used when operated in approved mode
  • If the module implements a KDF from NIST SP 800-135rev1 and this KDF has not been validated by the CAVP. Please refer to IG D.C.