6

Some vendors appear to advertise their products as using "FIPS 140-2 compliant algorithms & ciphers". However, some of these products cannot be found on the NIST website that lists validated cryptographic modules. What does this really mean for customers who wish to use the product?

Is a product's use of standardized, "FIPS 140-2 compliant algorithms & ciphers" sufficient to meet the requirements of a government organization or contractor? Or does a product actually have to be validated by NIST in order to meet government data protection requirements?

Iszi
  • 26,997
  • 18
  • 98
  • 163
  • 2
    I believe that a cryptographic *module* is defined as an implementation, whereas cryptographic *algorithms and ciphers* are (as the name indicates) just algorithms and ciphers like Diffie-Hellman, AES, RSA, etc. From what I can tell, NIST requires organisations subject to FIPS 140-2 to use FIPS 140-2 compliant cryptographic modules, which in turn can only utilise FIPS 140-2 complaint algorithms and ciphers. I can't find any guidance on whether explicit validation has to be performed on modules for correct compliance, though. – Polynomial Sep 01 '15 at 19:54

2 Answers2

6

I think the answer comes straightforward from this quoted paragraph (Module Validation Lists) -I emphasize the important thing in bold:

A product or implementation does not meet the FIPS 140-1 or FIPS 140-2 applicability requirements by simply implementing an Approved security function and acquiring algorithm validation certificates. Only modules tested and validated to FIPS 140-1 or FIPS 140-2 meet the applicability requirements for cryptographic modules to protect sensitive information.

As for:

What does this really mean for customers who wish to use the product?

NIST advises:

Users in Federal Government organizations are advised to refer to the FIPS 140-1 and FIPS 140-2 validation list

Validation list.

4

This is where you must read carefully.

  • Compliant means that the vendor believes they have followed FIPS encryption requirements and their product meets the specificaiton.
  • Certified means that the product has actually been tested by NIST and issued a certificate number.

Certification is an expensive and time-consuming process, and must be re-done after changes, so companies will take the "compliant" route.

FISMA and specific RFI/RFPs, etc will state requirements around certified modules/hardware/etc and during review will require the NIST certificate number, so be sure to read requirements carefully and be specific when sending requirements to the vendor if you will accept compliant versus certified products.

Edit - also be sure that you're looking at the correct -version- of a product. FIPS certification applies to a specific set of code. There are also usually operational requirements about OS settings, etc so the terminology will some times say "FIPS 140-2 certified mode".

Thusly, FooLock 1.0 may be certified, but FooLock 1.1 is not because even though it's the same source code, it uses a different MS .NET CLR.

FooLock's publisher may (without any intent to deceive) say FooLock 1.1 is FIPS compliant because the crypto module is "the same code" but it is not certified, and if you use FooLock 1.1 for a solution which required a certified product, as South Park says, you're gonna have a bad time.

lonstar
  • 141
  • 3
  • `s/encryption //` because FIPS defines other things than just encryption such as hash/MAC/signature, key generation and management, random generation, self-test, attack detection and reaction. And testing is not done by NIST itself, but by a private/commercial "Cryptographic and Security Testing (CST) lab" from a short list accredited by NIST; using their results, the formal certificate is issued by NIST and CSEC. (Concur with the rest.) – dave_thompson_085 Sep 02 '15 at 07:49