FIPS 140-2 Compliance is required for procurement of IT systems for the US Federal Government. It is also mandatory for US government contractors and also for US state and local governments where projects are spending federal money. No FIPS Compliance => no purchase, and since the US government is a really big purchaser of IT systems, it’s a big monetary deal, and everyone wants to be “FIPS Compliant”. What it means outside of procurement is “high quality crypto” and this has inspired many in commercial spaces, notably including banking and finance, to use FIPS compliant crypto for their IT operations. This post reviews what “Compliance” means and provide some detail on the related terms of “Validated” and “Approved.”

It’s more than the US. The CMVP (Cryptographic Module Validation Program) is a joint program between the US National Institute of Standards and Technology (NIST) and the Communications Security Establishment Canada (CSEC).

What is “FIPS 140-2”?

  • FIPS is “Federal Information Processing Standard”.  There are lots of FIPS standards.
  • FIPS standard number 140 is the FIPS standard for cryptography
  • FIPS 140-2 is the second revision of FIPS 140

History: Requirements for quality cryptography were first defined with the FIPS 140 definition in 1994. An update to the FIPS 140 standard was released in 2001 and is titled FIPS 140-2. Here is a link to the spec. Now 2017 and FIPS 140-2 is still the standard but there is a “-3” is in the works, and it has been in the works for a very long time. Even without a change to “-3”, NIST continues to introduce requirements, so the things that are FIPS 140-2 in 2017 are not really the same things that they were in 2001 and stuff that was compliant then, no longer meets spec. The standard is the same number, but the requirements do change over time.

FIPS Compliance requires

  1. Use only FIPS approved / NIST recommended crypto algorithms (e.g. AES, SHA-2). NIST list
  2. Crypto must be implemented in a NIST validated crypto module. Official list
  3. Crypto module must be placed into FIPS Mode
  4. Vendor must document how to use system in FIPS Compliant manner

Four lines and now we have a bunch more terms that need definition.

NIST Approved algorithms

The list of NIST approved algorithms changes a bit over time. SHA-1 for example used to be a perfectly acceptable hash, but at the end of 2014, NIST retired SHA-1 in favor of the SHA-2 family of hashes. NIST didn’t know of a SHA-1 collision, at least none they were admitting, but they were worried that SHA-1 was no longer up to the job of a cryptographic hash so they removed it from the list of approved algorithms. In February 2017, Google announced the first SHA-1 collision, link.  First, props on great work at Google and second, once the math against two pieces of data are shown to produce the same hash, the hash can’t be used when this matters (e.g. in digital signatures).

So, NIST deprecated SHA-1 at the end of 2014 and the crypto community publicly achieved a collision in February 2017. A great run though, SHA-1 had a 12-year life. While described as “dead”, SHA-1 will be around in some forms for years to come. A collision is hard to achieve, really hard and SHA-1 is still great compared to many other hashes, but it is no longer NIST recommended for digital signature.

For people wearing programming hats, this means products must change over time. There was a large effort in Citrix a few years back to change everything in XenApp and XenDesktop from SHA-1 to SHA-2. Changing the hashes, and dropping ability to use the old when in FIPS mode means breaking some aspects of backward compatibility. Example, receive a connection from a Citrix Receiver that only speaks SHA-1 to a XenApp or XenDesktop server that is in FIPS Mode requiring SHA-2, what do you do? Want to claim FIPS Compliance, you must be able to operate with only NIST algorithms.

Just to make the world more complex, I sent this blog post out to some Citrix security experts for review and got back a description of the difference between FIPS Approved and NIST Recommended. The response was so good that I include it here, paraphrased:

There’s a small set of FIPS standards like SHA-3 which are have their own FIPS standard numbers, SHA-3 is FIPS 202, and AES is FIPS 197. These are FIPS “Approved”, but to get FIPS approved, they have to go through the Federal Register, and it’s a slow process. There’s a much larger set of NIST standards, e.g. NIST SP 800-185 which is SHA-3 derived functions. These are NIST Recommended and they don’t go through the Federal Register.  So, for FIPS 140-2 (which is itself a FIPS standard), you also need to consider both FIPS and NIST standards. Most people don’t care about the distinction, but in the standards the phrase “FIPS Approved/NIST Recommended” appears all over the place.

FIPS Validated module

A FIPS Validated crypto module is a crypto module that has been independently determined to be valid implementation. Notice that this isn’t just validating that the math gets the right answer, it means testing and validating that the crypto module doesn’t leak key material and that it is otherwise strong against particular attacks. Sometimes people use the term “certified” for the activity of certifying a crypto module, but the official term is “validated.” Is the crypto module FIPS validated? The permitted responses to this question are “yes” and “no.” Is the crypto module on the NIST list or not? A crypto module is placed onto the NIST list of validated crypto modules after the independent test lab has issued a report to NIST stating that the crypto module passes testing.

Observe that this costs money. Getting FIPS Validated is an award of great value for a crypto module, certified good security! Getting there requires that the module is yes, of high quality and second requires that an independent test house validate that it is compliant. All of this costs money, but once validated, the crypto module is “worth more” and this flows down the product pipe. For example, the Cavium Nitrox crypto module used the FIPS versions of Citrix NetScaler MPX is more expensive than the similar card in the not FIPS version. People who care deeply about the quality of the crypto (Government, Banks, Insurance) end up paying a premium to get validated crypto modules and FIPS compliance.

FIPS Mode

“FIPS Mode” means that the crypto module has a switch to place it into a configuration where it will on-purpose fail all crypto that is not approved algorithms.  I was once under the view that once going to FIPS mode, the crypto module could not exit FIPS mode, wise people have told me that this is not the complete story (backward compatibility, market realities). When in FIPS mode, the FIPS module must fail all non-FIPS crypto. This comes up from time to time in Citrix XenApp and XenDesktop when I take customer inquiries that say a connection using Citrix SecureICA encryption failed to connect to a server in FIPS Mode, server rejects the connection and there’s an entry in the logs about rejecting an attempt to use non-FIPS algorithms. Answer, yes, that’s exactly what it does and exactly what it is supposed to do, reject the non-FIPS crypto when in FIPS mode. Want a FIPS configuration, use TLS as outlined in the FIPS configuration docs, more below.

FIPS Compliant

To be a FIPS compliant product, the vendor must document how to use the product in a FIPS compliant manner. This means specifying how to deploy the product in a manner that it will operate in accordance to the FIPS guidelines. For products with lots of parts, a precise level of detail in configuration is needed and for XenApp and XenDesktop, these are provided in documents here. See FIPS documents under heading “Security Standards Documents and Resources.” Notice that documents exist from MetaFrame XP FR3, all the way through current releases of XenApp and XenDesktop. We have been FIPS compliant for a very long time. The NetScaler FIPS Compliance documents are here and XenMobile here.

FIPS Levels

Under validation, I described how a crypto module must be strong against attack and not leak key material. This comes at 4 defined levels of achievement, titled Security Levels. The NIST page has details, the quick version is:

  1. Basic security requirements. Generally, the only level achievable in software. It is still a strong statement. The crypto module must defend against timing attacks and power measurement attacks and the “branch” logic in the crypto module must not change based upon bits in the key. This is hard and requires careful code to implement successfully. Is a FIPS validated crypto module better than a non-FIPS module that computes the same math? Answer: Yes, yes it is.
  2. Tamper-evident. If the crypto module is attacked, there will be evidence that it was attacked. Example: holes drilled into the printed circuit board to get to wires at lower layers of the board that are otherwise not easily accessible.
  3. High probability of detecting and responding to attack. Crypto module detects attack and takes action to defend.
  4. Highest level. Module is very resistant to attack. There is a high probability of detecting attack (power, temperature, drills) and module includes procedures to actively flush all key material when deemed under attack.

With this, you will often see statements in FIPS Compliance that the system is using the [ABC] crypto module operating at “level 2.” Or, the system is using the Windows operating system provided FIPS crypto module, at level 1.

Summary

FIPS is good and FIPS Compliance is a statement to quality security. FIPS compliance comes down to using only approved crypto algorithms, implemented in a validated crypto module, along with guidance on deployment in a FIPS Compliant configuration.

Joe Nord
Security Product Manager
Windows App Delivery, Citrix Systems

syn17-d-banner-blogfooter-729x90