The recent news of SAIC being dinged for not protecting US military TRICARE medical information with standard AES encryption and suffering a data loss is interesting. While the details are still thin, it appears that the data was encrypted, but not with a standard AES encryption method. The HITECH Act proposed data security rules make specific reference to AES and other NIST standards.

We don’t know which encryption method was used to protect the data. It could have been a home grown method of encryption, or it may have been a widely accepted encryption method that was just not a part of NIST standards. But it apparently doesn’t matter. If you are not using a NIST standard method of encryption, you are in violation of the compliance requirements.

I think it is going to take some time for the implications of this to settle in. Here are some rather unorganized thoughts:

Over the last two years I’ve seen at least FOUR instances of vendor “AES” encryption solutions that actually weren’t AES encryption. In one case, a point-of-sale vendor implemented an AES encryption library with a 256-bit AES block size. The AES standard (FIPS-197) only allows the use of a 128-bit block size.  The company running this software had no idea that they weren’t actually running an industry standard method of encryption.

In another case a customer was running AES encryption with a non-approved mode of encryption. The underlying encryption library was AES, but the mode was not a NIST-approved mode of operation. This was a distinction lost on the company running this “AES” solution. But it seems likely to me that they were out of compliance and at risk in the same way SAIC was. This company is going to have to rip out the current solution and replace it with something that is actually compliant. That seems like such a waste of time and resources.

In one of these cases the software was provided by a “security” vendor. This vendor sells encryption and key management software specifically to meet encryption compliance regulations. That’s very sad.

With the best of intentions and with deep knowledge of encryption protocols, you can still make mistakes when developing an encryption solution. It is hard to get this right. And weak vendors without the commitment and passion to get it right represent a risk to everyone. So, if you are a vendor of encryption solutions, what do you do to insure that you are getting things right? You learn to not trust yourself so much, you invest in independent review of your solutions, and you invest in independent certification. Today we would never release an encryption product without subjecting it to NIST certification and independent review.

If you are a company facing an encryption project, how will you select a security vendor for your encryption libraries and encryption key management solution? How will you know that their AES encryption is really based on the NIST standard? Are you ready to trust the claims of a sales person? I wouldn’t, and I don’t think you should, either. If a security vendor can’t show you a formal NIST AES Validation certificate, or a FIPS-140-2 certification, you should run for the nearest exit. You just have way too much to lose.

If you think that the HITECH Act is unique in its reference to NIST standards, have a look at the proposed Federal Privacy Law (Senate Bill 1151) that passed out of the Senate Judiciary committee last week. It is likely to empower the FTC to propose standards for encryption and encryption key management, and the FTC is likely to look to NIST for these standards.

The writing is on the wall, or rather, it’s on the Internet at www.nist.gov.

Learn more about proper encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

Patrick