I’ve always liked those Holiday Inn Express commercials with the theme of “Stay Smart.” The commercials portray an “expert” stepping in to save the day. In one, a “nuclear expert” takes charge of a reactor about to melt down. In another a “doctor” arrives to deliver a baby just in the nick of time. The tag line is funny because the so-called expert turns out not to be a nuclear scientist or a doctor, but just an average person who stayed at a Holiday Inn Express. That made them “smart.” Don’t worry; I’ll bring this discussion back to encryption momentarily.
Just last month, reports surfaced of broken encryption security for some Kingston, Verbatim, and SanDisk secure USB storage devices. Not all of the vendor’s devices were affected, but some of their most popular products were. All these products were NIST-certified, causing some industry commentators to erroneously question the certification process. Being a big believer in independent certification, I’d like to weigh in on this controversy and set the record straight.
As it turns out, the weakness, in these devices, was not in the actual AES encryption, but in the key management processes. All the affected vendors quickly released replacements or patches to fix the problem, which is the right thing to do. But it was fascinating to watch some of the responses to this problem. Many commentators complained that the FIPS-140 testing was faulty, or that FIPS-140 testing was irrelevant. The implication is that FIPS-140 does not really give you any assurance of security, and therefore, also by implication, that it is not important.
This is really the wrong conclusion. Let me talk a little about FIPS-140 certification and what is does mean.
First, FIPS-140 certification is not a guarantee of security. It is an assurance that encryption and related security algorithms have been implemented in compliance with published standards, that an application uses good practices in exposing it’s operational interfaces, that start up tests validate that the application has not been modified or corrupted, that cryptographic material is not exposed in application logs or leaked to memory, and that an independent expert has reviewed the source code. Going through a FIPS-140 certification is a grueling process for an encryption vendor and almost always results in finding some issues that need to be addressed to make the product more secure. Companies that engage in FIPS-140 certifications produce better products, and become better security designers in the process.
Is the FIPS-140 testing and certification process perfect? Of course not. That’s not a standard anyone can meet. In fact, NIST is working on a project right now to enhance the process. Believe me, the new certification process (probably to be named FIPS-140-3, for version 3) will not be weaker than the current process, it will be better.
The lesson from the encrypted USB problem is not that FIPS-140 certification is meaningless. It’s that doing encryption right is really difficult. If you want a secure USB storage device, you would NEVER consider using a product that was not FIPS-140 certified. We have plenty of experience of broken security on non-certified products. Problems with certified products are rare, but do happen. Usually you will find that a problem with a FIPS-140 certified product is with some aspect of the application that was out of scope for the certification. That’s the case for the encrypted USB devices that had problems.
To bring us back full circle, I just want to say that no responsible Enterprise should trust a non-certified USB device, anymore than you or I should trust a “doctor” to perform surgery because that “doctor” stayed at a Holiday Inn Express. The sad fact is that many large corporations today are putting their trust in encryption vendors who have not FIPS-140 certified their products. The management of these companies would never consider using a $100 secure USB device without certification, but do entrust the protection of huge amounts of sensitive data to non-certified vendors. In this age where too many try to pass themselves off as experts, it often takes an organization like NIST to certify the expertise behind something as important as encryption.
I’m proud of our NIST certifications – we will never back down from our commitment to provide you with the best security products and our commitment to independent certification. You can learn more about FIPS-140 certification on our web site, or directly from NIST at www.NIST.gov.
Patrick
Just last week a group of cryptographers announced a practical attack on some versions of 256-bit AES encryption. This announcement initially created quite a stir in the cryptography community, before reality set in and the scope of the vulnerability was defined. The attack is quite sophisticated and represents a major step toward breaking AES. While you might think that 256-bit AES encryption is the strongest encryption you can deploy because it has the largest key, in fact, key size is only one aspect of the strength and reliability of encryption. And in this case a weakness in key handling at the 256-bit level exposed a weakness in some, but not all, versions of AES encryption.
At this point you are probably asking yourself – am I at risk?
The answer is – that depends. Is your encryption solution NIST certified as Patrick Townsend Security Solutions are, or is it an open source or proprietary solution that some programmer hacked together on their own?
The recent attack that everyone’s talking about used 256-bit AES encryption that implements 10 or less rounds (repetitive processing that transforms the input using the encryption key) during the encryption process, combined with a set of related encryption keys and known plaintext values. The good news is that NIST defines the minimum number of rounds for standard 256-bit AES encryption at 14. There is no known practical attack on 256-bit AES encryption that implements 14 rounds.
If you are using a NIST-certified AES encryption solution you can now relax (our Alliance AES encryption solutions are NIST certified on all platforms).
If you are NOT using a NIST certified solution, or if you don’t know if your solution is NIST certified, you have some work to do. First, rather than ask your vendor if they are NIST certified, you can determine if your vendor has completed NIST certification by looking at the NIST AES Validation list. A NIST AES validation is specific to the operating system and hardware platform. Be sure you find a match with your implementation. If your vendor is not on the list it’s time to pick up the phone, call your encryption vendor, and ask some questions:
• Does your implementation use 256-bit AES encryption?
• How many rounds are used, and can the number of rounds be independently verified ?
• Where did you get your implementation of AES? Which Open Source version did the developer start with?
• Is the solution NIST compliant? Can the vendor prove it? If it is not NIST certified, why not? Do they have a plan to get their solution certified?
• Can the vendor replicate the published NIST encryption results to validate that the code is working correctly?
You should get some clear answers to these questions. If your vendor experiences one of those “deer in the headlights” moments, or if the answers are not clear and simple, you may have a vulnerable version of an encryption solution on your hands. Your vendor might say something like “Well, it’s an implementation of Rijndael, so it’s Okay”. This is why independent laboratory certification from NIST is important. Some older versions of Rijndael used a smaller number of rounds, and less talented encryption programmers may not even understand what the difference is.
NIST certification is not an absolute guarantee that a security vendor has done encryption right. Nor is it a guarantee that there won’t eventually be a weakness in the encryption algorithm. But NIST does represent the very best in encryption standards and guarantees that your vendor has had some independent review of its encryption solution. Doing encryption right is important not only to guarantee that your solution is less vulnerable to attack, but also to give you the peace of mind that your data can be decrypted by you when you need it.
While this published attack on 256-bit AES will probably not pose a significant risk to your encryption strategy, it will serve as a wake-up call to many organizations that it is time to get serious about encryption vendors. Any serious vendor of encryption will take the minimum step of completing NIST certification. We all think it is a good idea for teenagers to have a driver’s license, security vendors should get NIST certified, too.
Bruce Schneier has a really good description of the attack and it is well worth reading. I really like Bruce’s view on security in general. He writes well on a wide variety of security topics and brings a nuanced view to the subject. You can sign up to get his email newsletter on his web site.
One last thought: the cryptographers who found this weakness were not up to anything bad. The study of encryption ciphers and the attempt to compromise them (called cryptanalysis) is an important part of keeping encryption secure. You REALLY should worry about using encryption that is home-grown, or out of the mainstream, because the only ones trying to find the weakness are the bad guys. And they are not going to tell you if and when they break your encryption. They are going to exploit it as much as possible and your business will suffer. Don’t wait for that to happen. Realize that the right time to take a good hard look at your encryption solution vendor is now.