On Preserving Formats

With RSA’s Data Protection Manager 3.5 (now available), we are releasing into our core product a mechanism in cryptography that has been gaining steam in the recent years: format-preserving encryption (FPE). While we have been implementing FPE for years with our Professional Services teams, we felt it was now time to formally add this to the product. Why, you may ask? Well, let’s look into that.

Typically when data is encrypted (AES, Triple DES, RSA, ECC, etc.), the encrypted data doesn’t look anything like the original. It is designed to be that way – because in most cases the output format of the data isn’t all that important. But, when you have systems have been built over long periods of time and need to talk to each other – the format of output becomes important.

FPE protects any kind of fixed-format data. Think credit cards, birth dates, social security numbers, account numbers… instead of turning it into a long blob, it keeps the format of the original data, making it easy for other systems or applications to use it. Very similar to tokenization, FPE-protected data looks like the original data BUT unlike tokenization, it uses a key.

This general goal of preserving some aspect of the original data is true of any FPE system. Most FPE systems give you the option to:

1. Preserve character set (Encrypt 10 numbers like SSNs, into 18 numbers)
2. Preserve length (Encrypt 16 numbers into 16 characters – binary okay, alpha okay)
3. Preserve some pieces (Encrypt 16 digit numbers into 18 digit numbers, but make sure the last 4 digits match)
4. Preserve all three; some pieces, character set, and length (Encrypt 16 digit card numbers into 16 digit numbers and keep the last 4 the same)

As with any technology, FPE has its advantages and disadvantages. FPE is a great approach for data that is resident for shorter periods of time in a transit system – think credit card processing, or claims processing in insurance. FPE is still encryption, so good key management is essential for a secure implementation. If format preservation over long periods of time is the use case, then Tokenization may be a better fit.

The consultant in me says, “it depends” (and the technical guy adds – “on the use case and data retention periods”). The good news is all of these options are available out of the box in RSA Data Protection Manager.

Vasu Nagendra

Sales Engineering Manager – Payment Security

As Sales Engineering Manager for RSA’s Payment Security Group, Vasu is responsible for strategic vision, solution architecture and customer integration for RSA’s encryption and tokenization solutions for global merchants and acquirers. He is an active participant in many industry standards committees related to encryption, key management, and tokenization. Vasu holds a MS degree in Electrical Engineering from Wright State University.