Menu

NIST standardizes payment card format preserving encryption

What is Format Preserving Encryption?

 

Normally, when encrypting data, the result is an unintelligible mess of seemingly random data. That’s ok since the point of encryption is to make something unreadable unless you know the corresponding key. However, it assumes that systems processing that data expect it to be in that unintelligible form.

 

Some modern payment platforms make use of point to point encryption (P2PE) to help protect credit cards from prying eyes. However, these systems often require upgrading multiple pieces of the payment ecosystem.

 

This is where format-preserving encryption (FPE) comes into the picture. Format-preserving encryption does exactly what it says. Each implementation has enough awareness of its purpose in order to fully encrypt data, but produce output that looks like it’d be plausible.

 

For example, if you applied a phone number FPE system to the number +1 (555) 123-4567, it might output +1 (555) 340-0413. This is important for payment systems since if FPE is implemented successfully, then only the point of entry device and the FPE service provider would need to upgrade their systems.

 

Any existing systems expecting to see a credit card number would continue to do so, unknowingly operating on an encrypted number.

 

Challenges to FPE

 

There are existing FPE systems already in place in the payments industry, but they have some challenges to overcome. Payment systems are surprisingly diverse and some early systems made assumptions that were not universally applicable.

 

Some operated only on cards subject to PCI DSS and left proprietary or fleetcards unprotected. Others expected card numbers to always be 16 digits in length with a 6-digit BIN/IIN at the first. Yet more don’t take into account the fact that most, but not all, cards include a checksum as the last digit; this basically means that the last digit must be calculated based on the output of the FPE system.

 

But perhaps the biggest challenge is that it seems as though everyone has their own favorite FPE system and none of them are quite interoperable.

 

Enter NIST

 

To help address some of these challenges, the National Institute of Standards and Technology (NIST) has issued NIST Special Publication (SP) 800-38G, Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption.

 

This standard formalizes 2 ways to perform the encryption part of FPE. It is important to understand that does not specify what parts of card data to encrypt; the FPE algorithms can even be used on completely different data, such as medical records or other personal data.

 

This means that it could form the foundation of future frameworks, but is not an end result in itself. Fortunately, it does still address several concerns in previous systems.

 

In today’s systems card numbers are often 16 digits. The first 6 digits and last 4 digits generally must be available in an unencrypted form for payment applications to function. Therefore, in the normal case 6 digits would be encrypted using FPE. However, some card types have number that are shorter or longer.

 

The algorithms within NIST’s new standard are flexible enough to accommodate a wide variety of data types, including variable length payment card numbers. There are at most 1 million possible values when 6 digits of a card number are encrypted. While that may seem like a lot, modern computers can make a lot of guesses very quickly.

 

To help mitigate this, NIST includes “tweaks” into the algorithms. These “tweaks” function much like the salts in a cryptographic salted hash. They are a non-secret bit of data that is mixed in to make each encryption operation more unique. This prevents compromise of any particular card number from also exposing all the others.

 

Conclusions

 

There is no guarantee that a FPE protected card number won’t coincidentally be the same as some other live card number. What’s the likelihood of this happening? For this reason alone, it’s probably wise to still treat FPE protected data as sensitive and restrict access to the encrypted form.

 

PCI DSS requires that access to encrypted data be restricted anyway. Using true point to point encryption for payments, especially a PCI P2PE validated system, is still better protection than using FPE.

 

If nothing else, encrypting all the digits of a PAN is undoubtedly better than encrypting fewer. Like so many things in security, it ultimately comes down to a cost-benefit analysis. FPE is likely to be cheaper or easier to implement, so is that good enough for you or is P2PE a better route?

________________________________________

 

Contributors

 

Ian Groves, Application Security Risk & Compliance Manager, and Patrick Watson, Application Security Architect

 

Ian Groves has worked in payment card processing for 25 years. He brings a strong background in analysis, operations and payment card standards, rules and regulations. Ian's work includes experience with industry organizations such as UKCards and EPAS to define standards. Through these organizations, he has worked with schemes and banks to deliver new solutions to merchants. He is now focused on software compliance, security and risk management within NCR.

 

Patrick Watson is an Application Security Architect specializing in electronic payment systems. Working with over 50 payment processor interfaces,  Patrick has designed and implemented many of the security systems protecting consumer credit card and personal data. No stranger to PA-DSS and PCI DSS, he continues to champion security beyond compliance. He holds a BS in Computer Science from the Georgia Institute of Technology in addition to CISSP, CSSLP, and CIPP/US certifications.