×

FIPS is not a dirty word

Kevin Christopher Cloud Platform Security Architect, VMware

 

Ask a security engineer about FIPS validation, and you are likely to get a negative reaction. FIPS has a reputation for bureaucratic detail, 9-month paperwork processing times, and general inflexibility. All this in support of “validated cryptography”, when we all know cryptography would not work at all if it were incorrectly implemented. (That’s the whole point of cryptography.)

 

After having spent half a decade implementing FIPS within a well-known flagship product, I can report it has some positives.

 

The most important improvement FIPS has brought is eliminating – fumigating – obsolete cryptography. The number of places that still used MD5 for hashing (MD5 password hashes in test code were particularly egregious!) or otherwise use a weak hash to implement compare-by-hash was staggering. Many people claimed to just use MD5 because it’s faster – which is not actually true. I have lost count of the number of “yes, but is this must-ship in the next release?” or “when is the latest you need this by (so I can do other features first)?” procrastination answers along the way. FIPS is a beautiful forcing function that gives an unequivocal answer: insecure crypto is never okay. And you don’t even need to go through a FIPS certification to say that.

 

The other major benefit is being reminded of the value of self-tests. FIPS requires several categories of self-test, run in a customer (production!) environment, to ensure every CPU / OS / code combination works prior to use. In the time I have been working on FIPS adoption, FIPS self-test failures have been the first to indicate a handful of CPU or operating system bugs because they are sensitive to failure modes most software engineers would never think to exercise (broken RDRAND instructions, stuck RDTSC bits, signal handlers that did not preserve new registers). Testing pipelines cannot run all possible environments, but embedding (cheap) self-tests into a shipping product helps identify when an environment differs from your expectations.

 

FIPS – actually getting a FIPS validation – is painful. Behind the scenes, FIPS is using the same techniques we all know to get those validated results. Eliminate old code before it rots. Test pipelines are not always representative. Even the most annoying of (FIPS) processes was created for good reasons.