Freely subscribe to our NEWSLETTER

But virtually all of our clients also have to comply with at least one, and often multiple, set/s of government/industry regulations which may dictate what sorts of technologies are considered compliant — typically one that uses a standard that has been tested and approved by an agency such as National Institute of Standards and Technology (NIST).

When Protegrity provides technologies using algorithms or other techniques that are not clearly in adherence with compliance standards — in other words, a company deploying this technology could find itself slapped with fines and other penalties for being out of compliance — we clearly state that fact.

Take, for example, Format Controlling Encryption ( also called Type or Format Preserving Encryption). This technology preserves the format of the original, unencrypted data set while still protecting the data.

Data that is encrypted using traditional methods has a different format than it did before it was encrypted — for example, an encrypted Visa credit card number does not have 16 distinct numerical fields after encryption. Applications that some enterprises use to store or work with credit card numbers may have been configured to require those 13 (or more) digits. So you would need to modify the programs, an often costly or sometimes even impossible process.

By preserving the character-by-character format of an encrypted string of data, that data can be plugged into existing fields with no need for database schema changes. This allows encrypted data to be used, for example, in testing and troubleshooting in less-controlled environments such as non-production servers, regardless of infrastructure or application format requirements and with no worries that the test data will be exposed.

It’s a highly useful technology — but it’s based on a modification of the AES algorithm that is currently not approved by NIST so it’s not considered PCI-DSS compliant.

The PCI Data Security Standard states that “strong cryptography” must be deployed as acceptable encryption. Below is the definition on the PCI Council’s website of “Strong Cryptography.”

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”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. 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 (http://csrc.nist.gov/publications/) for more information.

At Protegrity we clearly tell our clients and potential clients that FCE technology is not intended for use in all scenarios and environments, nor is it approved for use under standards like PCI-DSS. Other companies prefer to vaguely note that their implementations are a “mode” of NIST-recognized AES. But however you describe it, a mode or variant is NOT one of the standard, approved implementations of AES. They also fail to mention that the technology they have developed to implement this form of encryption required significant alternations to the standard mode of the AES algorithm and that one methodology (FFSEM) can only handle digital data sets between 9 and 19 in length.

NIST is currently considering approval of several vendor implementations of FCE, including Protegrity’s FCEM. Until then, FPE (Format Preserving Encryption) is an unproven algorithm with no approval from PCI DSS Council or NIST – and is currently not approved for securing cardholder data.

There are a lot of promises being made about new technologies that can remove systems from the scope of PCI-DSS by purging sensitive data from systems. But we haven’t found any Level 1 or Level 2 merchant that was able to actually get rid of all their card data even though they implemented tokenization or FPE/FCE. Some of the reasons include business requirements, the cost to change their production applications, and the difficulty of actually finding and purging all their card data. Our point is simple: end-to-end encryption and tokenization will likely exist side-by-side in nearly all large and most midsize businesses for the next 2-3 years, so suggesting that one can take the place of the other for such organizations does not take into account the reality of the large, multi-channel merchant or service provider. (Protegrity offers tokenization, and strong encryption along with FCE in our data security solution).

And we also advise businesses to watch out for solutions that use FPE and other unapproved technologies in solutions such as tokenization — check the encryption mode against the NIST list and make sure its specifically listed and pay no attention to vendor promises that the solution uses a variant or subset of an approved mode.

For more on this important subject see Securosis’ post (and readers’ comments) on FPE here http://securosis.com/blog/format-and-datatype-preserving-encryption.