Working With FIPS 140 Crypto Standards

To explain the 140 series of the Federal Information Processing Standards (FIPS) in plain talk and without dozing off is challenging, but let me give it a try:

FIPS cryptographic standards specify design and implementation requirements for cryptographic modules. Software and hardware vendors can contract with accredited laboratories to validate their modules against these standards, which then allows others to use those modules in computing environments that must adhere to the U.S. government’s information processing standards.

Two questions come to mind.

First, what is a cryptographic module? A module might be a piece of software, hardware, or a combination of both. For example, RSAENH.DLL on various Windows platforms is FIPS complaint. Another example would be the Samsung crypto modules running on Android devices like the Galaxy S4.

Second question, from a software developer’s perspective, is who must use FIPS compliant modules? The obvious answer is most anyone working directly or indirectly for a department or agency of the United States federal government who is handling sensitive but unclassified data. However, FIPS has also made inroads into private sector healthcare and banking businesses, as both industries store and transmit sensitive data like credit card numbers and personal health information.

The FIPS Switch

Some businesses will enforce the use of FIPS compliant algorithms by flipping the “FIPS switch”.  This is a setting on operating systems that ensure applications only use FIPS verified cryptography algorithms. You can flip this switch on Windows, as well as OS X and other operating systems and devices.

On Windows, the FIPS switch impacts the entire system and all applications, from BitLocker to Internet Explorer and Remote Desktop. The FIPS switch will also impact the code you write. Even if you don’t want to use a FIPS compliant algorithm, if your C# code executes on a Windows machine with the FIPS switch on, you’ll have to use a FIPS compliant algorithm or the code will fail.

For example, with C#, the managed .NET implementations of AES encryption are not certified, so the following code fails with an exception.

using System.Security.Cryptography;

static class Program 
{
    static void Main()
    {
        var provider = new AesManaged();
    }
}

Unhandled Exception: System.InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.

Instead of using AesManaged, you’ll need to use AesCryptoServiceProvider, which calls into native, verified modules.  And just so you know, your application won’t be the only one to face these types of exceptions, as everything from Visual Studio to Internet Explorer and even frameworks like ASP.NET and databases like MongoDB have had (or still have) troubles with FIPS at one point or another. Be careful when you flip on FIPS that you don’t cripple your own development machine, you might need to reserve FIPS for a testing environment.

The FIPS Whip

One of the issues you might run into with the FIPS switch is how the system will use brute force to deny access to uncertified encryption modules. There is no awareness from the OS of why an application might choose to use a specific algorithm. In the case of AES the brute force approach might make sense, but when you start to think of algorithms like MD5 the situation is grey. MD5 might be used cryptographically to generate a message digest, but someone might have also chosen MD5 to generate a hash to use as the key value for plain text data in a distributed cache. But, MD5 is considered weak from a crypto perspective, and the following code will also fail with the exception we saw previously, even though the code is using a crypto service provider.

using System.Security.Cryptography;

static class Program 
{
    static void Main()
    {
        var provider = new MD5CryptoServiceProvider();
    }
}

To run on a computer with the FIPS switch on, then, you need to be careful about your choice of anything cryptographic.

The irony of the FIPS switch is that the system can only prevent what the system knows about. Microsoft programmed the .NET crypto classes to respond with an exception when used inappropriately, but there are other libraries and platforms that will run any kind of cryptographic algorithm on a machine with the FIPS switch on. For example, I can still run the following code in Node on a FIPS enabled Windows machine.

var crypto = require("crypto");
var message = "The Magic Words are Squeamish Ossifrage";
var hash = crypto.createHash("md5").update(message).digest("hex");

console.log(hash);  

So Is The FIPS Flag Useful?

I think the question is debatable.  The FIPS flag will keep the honest applications honest. But the FIPS flag doesn’t guarantee that an application encrypts the right data, or that an application encrypts data at the right time, or that an application developer doesn’t “work around” the FIPS flag by writing their own algorithm with XOR and clocking out. The FIPS flag also can’t stop a user from storing their passwords on a yellow sticky note affixed to the back of an LCD monitor.

The real question should be: “is the data on a FIPS enabled machine more secure than the data on a machine without the FIPS flag?”

I’d say the answer is unquestionably a “no”, and system administrators should know the FIPS flag is not a silver bullet for security.