Updating FIPS 140-2

In the early days of Internet security, security consultants would often show a picture of an unplugged computer and tell you that the only safe computer was one that was unplugged. Only slightly more risky was one that was turned on but not connected to a network. Connecting your computer to a network was supposed to have the potential to cause all sorts of Bad Things to happen to you, and it made achieving a reasonable level of security extremely difficult to achieve.

Today, not connecting a computer to a network is almost unthinkable, and devices like PDAs and cell phones are part of the same networks that desktop computers are. The security of such networks is not perfect, but they certainly function well enough to keep businesses running. Many new security technologies have been invented to make such networks practical for business use. Some security technologies have fallen behind, however, and one of these is encryption, although it might be more accurate to say that some standards for cryptography haven't kept up with changing technology.

The leading encryption standard is the U.S. government's Security Requirement for Cryptographic Modules, also known as FIPS 140-2. This standard defines the best practices that cryptographic engineers should follow, and being validated as following these practices is required for any cryptography used by the US government.

FIPS 140-2 is a relatively successful standard. It is now recognized by many countries outside the U.S. and is the basis for the new ISO 19790 standard. It has its roots in the world of hardware, however, and doesn't adapt as well as it could to today's world where cryptography in software is far more common than cryptography in hardware.

The FIPS 140-2 standard evolved over the past few decades from the original standard for the venerable DES encryption algorithm. The first standard for DES mandated that the algorithm be implemented in hardware, a requirement that lasted for 11 years until the requirements were finally loosened to also allow implementing DES in software. The FIPS 140-2 standard is the direct descendant of these ancient standards for DES and they still strongly reflect their hardware roots.

So why can this be a problem? The recent experiences of an unlucky defense contractor may illustrate this.

I recently talked to people in the information security department large defense contractor. They had just received a mandate to encrypt all email messages tothe government using a product that was FIPS 140-2 validated and was operating in a government-approved mode, so that all cryptographic functions were performed as required by the FIPS 140-2 standard. As they looked into doing this, they were surprised to learn that none of the available email encryption products they found would actually operate in a useful way in a FIPS-approved mode.

By following the requirements of the standard, they had to effectively disconnect their computer from the network, putting their system in the same fairly risk-free state that security consultants used to joke about. They couldn't actually send an encrypted email using a FIPS-validated email encryption product because the restrictions of FIPS 140-2 were so strict. Their systems would probably be very secure when operating in an approved mode, but they would also be relatively useless.

The root of the problem turned out to be a requirement of FIPS 140-2 that makes perfect sense for hardware, but doesn't make as much sense for software. And when the email encryption products were configured to operate in strict accordance with the standard, they couldn't actually function. If the defense contractor operated any of the available products in non-approved mode they would work just fine, of course, and it seems that many users of FIPS-validated products end up having to implement such a workaround to get their products to function.

You can't help but wonder if the provisions of a standard that frequently require workarounds in this way are even worth having. If products can't actually be used in an approved mode, is the standard useful, or should it be updated to reflect the realities of a world in which cryptography is implemented in software?

Cryptography is a difficult and arcane subject, so having a standard that rigorously validates its correct operation is a good idea. But the current version of the FIPS 140-2 standard seems to have gone a bit too far and needs to be updated to reflect the realities of modern technologies and the way in which they are used. This standard is currently being reviewed and updated, and NIST should ensure that the result of their efforts is compatible with the technologies that need to be used by both the public and private sectors. Software is here to stay, and the security standards need to reflect this reality.

Leave a Reply
