Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why you should use format-preserving encryption for legacy data

Luther Martin Distinguished Technologist, Micro Focus

A few years ago, I was giving a talk about data-centric security in Washington, DC. My message was that it is easier to protect the data that resides in today's complex networks than it is to protect the networks themselves—and encryption is a good way to do that.

Protect your data instead of your network. That's simpler, easier, cheaper, more secure, and  better in pretty much every way imaginable.

Until that day, I had believed that the problem I was talking about was pretty much limited to older companies with legacy systems built with no master plan over many years. To make this point, I showed a slide with a picture of the Winchester Mystery House in San Jose, Calif., juxtaposed with a picture of a new office building in downtown Shanghai.

The mansion was famously built over the course of 38 years, with no clear plan and at a cost of millions of dollars (in the money of 100 years ago and more), and the result is a bizarre structure with doors and staircases that don't go anywhere, and windows that look upon other rooms rather than the outdoors. Modern skyscrapers are built with carefully drafted plans and have state-of-the-art systems. 

Older networks are more like the Winchester mansion, built willy-nilly and at great cost, while newer ones are like that shiny skyscraper. I was immediately corrected by a few people in the audience. "No," they said. "My company is only a few years old, and we are already dealing with complex issues caused by legacy applications."

But my main point about how to protect data in legacy networks remains perfectly valid—and it can be applied more widely than I originally thought. And it's very useful to have a way to encrypt data in a way that does not interfere with the operation of your systems. 

Fortunately, you can do this in a way that will keep your auditors happy, with format-preserving encryption (FPE). Here's how.

How FPE can solve the problem

Fortunately, a recent NIST standard, Special Publication 800-38G, "Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption," describes how to do this.

The FPE modes specified by SP 800-38G have an interesting and useful property: Any encrypted values (ciphertexts) that are created using them look just like the corresponding unencrypted (plaintext) value. So a 16-digit credit-card number will get encrypted to another 16-digit value, a nine-digit Social Security number will get encrypted to another nine-digit value, etc.

The upshot: Systems that expect data in a particular format can easily handle data that is encrypted with FPE.

Why AES is not up to the job

This is not the case with other modes of the Advanced Encryption Standard (AES), such as the very common AES-CBC mode. Using this mode, a 16-digit value that represents a credit-card number might encrypted to a string such as BfA1lytW8I2kflOcQbOCUlX1yH+vAL1/nRoLgKkId+o=. This is longer than 16 characters, and most of it is no longer digits.

Unfortunately, this sort of change can be fatal in complex legacy environments, where lots of applications expect to get only 16-digit values and may not fail gracefully if they do not.

SP 800-38G specifies ways to encrypt sensitive data that can be fully validated to FIPS 140-2, the US government's "Security Requirements for Cryptographic Modules." Because of this, it is virtually certain that you can use the FPE modes that SP 800-38G describes to protect your sensitive data in a way that will comply with virtually any law or regulation. Encryption that has been FIPS 140-2 validated is recognized as being good enough to satisfy the regulatory requirements of the PCI DSS, HIPAA, etc.

A leg up on legacy data protection

It is possible to protect sensitive data in complex, legacy environments. Legacy systems can be hard enough to keep running. Don’t let them keep you from protecting your sensitive data, too.

Keep learning

Read more articles about: SecurityData Security