Warning: Plan Your Validation Carefully

I'm always interested in the comments of engineers who recently completed a FIPS 140-2 evaluation.  It's like the entire team had a meeting and played 'Not It', sealing the poor bastard's fate for the last year-and-a-half or so.  Seems fair, right?

It really isn't their fault.  Maybe they contributed to a NIST evaluation early in their career, and they made the mistake of putting it on their resumé.  Maybe they were cocky and volunteered, figuring that it couldn't be 'that hard' or 'that time consuming'.  Or maybe they simply had the misfortune of being late that day.  Regardless, they became responsible for a process that doesn't always make logical sense to an engineer and seemingly small early decisions have major ramifications for the entire lifespan of the product in question.

In some cases, veteran engineers with a pedigree in cryptography still get aggravated and befuddled by the inner workings at the CMVP.  The inspiration for this blog entry came from our friends at Oracle.  Darren Moffat, a Senior Principal Software Engineer based in the UK, vented about his experience in a post titled 'Is FIPS 140-2 actively harmful to software?'.

Before we go any further, the answer is no.  FIPS 140-2 is definitely not harmful.

Darren's frustration centers around the establishment of validation boundaries.

Why does the FIPS 140-2 boundary matter?  Well unlike in Common Criteria with flaw remediation in the FIPS 140-2 validation world you can't make any changes to the compiled binaries that make up the boundary without potentially invalidating the existing valiation. Which means having to go through some or all of the process again and importantly this cost real money and a significant amount of elapsed time.

He's absolutely on point. The boundary is a crucial strategy point for every validation, and as a vendor pursuing a FIPS certificate, you want to set it carefully.  There's no sense validating and locking in features that will require future updates.  From a user standpoint, this is exactly as it should be.  By insuring that any changes within the boundary require re-testing, buyers can be confident that a product's encryption module has been fully vetted in its current form.

Moffat goes on, asserting that engineers ought to be able to issue patches and bug fixes without invalidating the FIPS certificate.  I agree completely!  This is precisely why SafeLogic's CryptoComply family of validated cryptographic modules maintains a tight boundary.  The core crypto libraries are tested and validated, then left intact while the rest of the vendor's product can be updated as needed.  Users know that the encryption within is of the highest quality, and there are no negative side effects of active updates from the provider.  This is a win-win, and it all stems from establishing the correct boundary for the CMVP.

I don't agree with Moffat that most customers don't care about FIPS 140-2, and I don't agree that customers that care are only checking the box and don't worry whether the certificate is still valid.  Oracle's commitment to updating and patching their software is fantastic, but it should not come at that cost.  They invested a great deal in getting that certificate, and it should not be pushed aside so easily.  Earning a FIPS 140-2 validation requires time, money and commitment.  (Significantly less of all three if you use SafeLogic's RapidCert, but still enough to be relevant.)  If done correctly, there should not be a choice between validated crypto and properly updated software.  This is a toxic ultimatum for both the provider and the user, and it should be avoided.

To share your thoughts and stories from the trenches, tweet at us @SafeLogic!