Format-preserving encryption, or FPE, encrypts the plaintext of some specified format, such as a Social Security or credit card number, into ciphertext, while still preserving the original formatting of the plaintext.
Using FPE, a 16-digit card number encrypts to a 16-digit number, for example, and a nine-digit Social Security number encrypts to a nine-digit number. This differs from other ciphers that would produce ciphertext with a different data type and length.
Benefits of FPE
Why is it important to preserve a number’s original formatting?
There are two main advantages to using format-preserving encryption. First, encryption can be applied to legacy systems that require data in a particular format without the need for expensive and time-consuming changes to data models and code. This is why FPE is commonly used to protect sensitive data sets, such as payment card data, bank account details, Social Security numbers and personally identifiable information (PII), that are processed and stored in retail, healthcare and financial databases and applications.
Many retail, healthcare and financial applications are written in COBOL — yes, it is still one of the most common programming languages used by large enterprises. To bring these applications in line with data-centric protection standards, such as the California Consumer Privacy Act and GDPR, whole-disk or file system-level encryption is not a long-term option. Field-level data protection is often the only realistic approach to meeting regulatory requirements, but because COBOL is a strongly typed language, it would require extensive analysis and rewriting of code to handle encrypted data. FPE products encrypt data values that preserve the original data’s format and length, allowing it to pass through systems that only recognize a certain format, while remaining in a protected state.
The second major advantage FPE has over conventional encryption is that data such as credit card or Social Security numbers can still be used as a unique key to identify a row in a database. Data encrypted using a cipher block chaining mode changes the data’s value when it is decrypted and encrypted again. This means a lot of processing of FPE-encrypted data can be performed with the data in its protected state. Only in specific use cases — for example, passing a Social Security number to a credit card agency for a credit check — would the ciphertext need to be converted back into plaintext. Also, PII can be anonymized using FPE, thus making analysis of data containing medical information, for example, much more straightforward.
FPE vendors and NIST modes
Multiple vendors offer FPE in their products and services, including HashiCorp, Comforte, Futurex and Xmart Solutions. There are also various proposals to use FPE in other fields, such as in image processing and to improve the security of controller area networks used in connected cars.
Before adopting FPE, however, enterprise security teams should research its specific use cases and vendor implementation.
In 2016, NIST released “Special Publication (SP) 800-38G, Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption.” NIST originally considered three modes of operations — FF1, FF2 and FF3 — using the Advanced Encryption Standard block cipher algorithm.
FF2 never got approved. In 2017, researchers performed a cryptanalytic attack on FF3, rendering it unsuitable for general-purpose FPE because it did not achieve the intended 128-bit security level.
In response to the attack, NIST updated FF3 to FF3-1 in early 2019. The update addressed potential vulnerabilities where the number of possible inputs — that is, the domain size — is sufficiently small, for example, using the middle six digits of credit card or Social Security numbers. In these cases, there is simply not enough entropy to create a secure output that cannot be reverse-engineered. In SP 800-38G, the domain size for FF1 and FF3 was required to be at least 100 and recommended to be at least 1,000,000. In the revision, the domain size is required to be 1,000,000. Organizations considering FPE must ensure potential products and services adhere to the updated requirements.
FPE vs. tokenization
Alternative format-preserving protection approaches to FPE, such as tokenization, can be used as long as the implementation isn’t too challenging. Tokenization exchanges sensitive data with randomized values in the same format but that has no intrinsic value of its own. The original data is stored in a secure data vault. This is not the same as encryption. Encrypted data can be decrypted with the appropriate keys, whereas tokens cannot be reversed because there is no mathematical relationship between the token and its original value. This means there is greater flexibility with the breadth of tokens the data can be converted to.
