Townsend Security Data Privacy Blog

When encrypting data, the most widely accepted cryptographic standard is the Advanced Encryption Standard (AES).

AES is defined by the National Institute of Standards and Technology (NIST) in the FIPS-197 standards document. AES supports nine modes of encryption, each of them having been extensively tested and vetted for security, recovery, and durability. When compliance regulations make reference to “industry standard encryption”, they are referring to the encryption modes identified in the NIST documents on AES.

Other modes used in AES are not NIST certified and are not even certifiable. Some products offer only the CUSP mode of encryption, which is not NIST certified and not certifiable. CUSP mode encryption is only implemented on IBM i and IBM z platforms and is not interoperable with other encryption modes. The CUSP mode of encryption has not been proposed or adopted as a NIST standard, and has not been generally reviewed or accepted by the professional security community.

Modes of encryption are recommended by NIST after they have been extensively reviewed by the professional cryptographic community. This is an international group of cryptographers whose long experience and analytic work are important to the vetting of proposed modes of encryption. In some cases it takes years of work before a mode is approved by NIST; many mode submissions are never approved for use.

There are several potential problems related to the use of the CUSP mode of AES encryption.

The CUSP mode of encryption is not included in the NIST list of recommended modes, and has not been submitted to NIST for consideration. It is therefore not a part of the NIST standards, or of any other generally accepted body of standards, and has not been formally reviewed by the cryptographic community. Therefore, the use of CUSP mode would be outside the scope of most data security regulations.

Further, there is no NIST certification protocol for the CUSP mode of encryption. It is not possible to claim that an encryption product using CUSP has been certified by NIST, or that it is in anyway compliant with the NIST standard.

Organizations contemplating the CUSP mode of encryption should be aware that their data protection mechanism could fail to provide “safe harbor” from breach notification requirements, and may not limit their legal liability in the event of a data loss.

The solution?  Most software vendors choose to certify just one or two modes of encryption, and on one key size. The Townsend Security Alliance AES Encryption products are NIST-certified on the five commonly used modes for data encryption, and all three key sizes for all major Enterprise platforms (Windows, Linux, UNIX, IBM i, and IBM z).  Townend Security Alliance AES Encryption is certified, compatibile, and complete.

Download a free 30-day evaluation of our Alliance AES Encryption now.

In our encryption practice we often help customers integrate the exchange of encrypted data between different applications within the organization, and between their own applications and a vendor’s or customer’s application. It is truly amazing to me how often we encounter non-standard encryption that makes this integration very difficult. The problem is not the lack of standards for encryption. Most compliance regulations provide clear guidance and references to encryption standards. Here is what the PCI Data Security Standard (PCI DSS) Navigation Guide says about encryption (my emphasis):

The intent of strong cryptography (see definition and key lengths in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "home-grown" algorithm).

Strong Encryption:
Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 for more information.

The problem seems to be a general lack of knowledge about encryption. And this applies to some vendors of encryption solutions. Here are a couple of examples:

One of our customers was having trouble decrypting a field with our software that was encrypted on a Windows server with “256-bit AES using CBC mode”. That seemed to be a pretty straight-forward task. Yet we couldn’t get the data decrypted properly. The output just looked like garbage. We spent a fair about of time with the customer verifying that they had the right decryption key, that the initialization vectors for the decryption were specified correctly, and that our software was being used correctly. But nothing was working. We then asked the third party software vendor to share their AES source code with us.  In this case the vendor was very accommodating and let us review their source code implementation of AES encryption.

Voila! The source code showed that the implementation was using a 256-bit block size for the encryption algorithm. The AES standard (FIPS-197) requires the use of 128-bit block sizes. The use of the larger block size meant that this was not even AES encryption according to the industry standard. The vendor fixed their implementation and the project was successful. But our customer spent a lot of time and money resolving the problem.

Another example of getting into trouble occurred with a customer who deployed an AES encryption solution that used the CUSP mode of encryption. This rang alarm bells right away.  We knew that CUSP was not one of the NIST approved modes of encryption, and we had never encountered it before. We quickly learned that CUSP stood for “Cryptographic Unit Service Provider” and was implemented by IBM in a couple of their server products. This customer had a couple of problems. CUSP mode was not a standard mode of encryption, and data encrypted with CUSP was not going to be decrypted by any of the standard open source or commercial products in the market. So this customer was locked into an incompatible encryption strategy.

The second problem is that the CUSP mode of encryption is a proprietary protocol.  The PCI DSS clearly states that strong encryption must be based on industry standards and not proprietary protocols (see above).  As I interpret the PCI DDS requirements for encryption, a customer using CUSP mode would be out of compliance. That’s going to hurt the next time a QSA takes a hard look at your encryption implementation.  We recently published a white paper on the weaknesses of the CUSP mode of encryption.  Click here to download it.

One way to insure that your AES encryption software is compliant is to look for a NIST certification. A NIST AES Validation certificate, or a NIST FIPS-140 certificate, is pretty good assurance of compliance. The FIPS-140 certification process requires AES Validation, so that certification is incorporated by reference. That’s why either certification will give you the assurance that AES encryption is being done according to the standard. Lacking certification, you are relying on the promises of a vendor or developer who may be ignorant, or have a motivation to be less than forthcoming. Not a good situation to find yourself in.

Both of these customers spent a fair amount of money fixing the problem.  An entirely avoidable expense.

Patrick