Previously we looked at Format Preserving Encryption (FPE) its characteristics and suitability for application in solutions intended for PCI DSS. To recap, FPE is an encryption method that produces cryptograms that share many of the formatting characteristics of the plain text and has a wide range of potential applications beyond PCI. The article showed that FPE can meet PCI requirements for strong encryption. It also described concerns where (in some implementations of FPE) the encrypted data can so closely resemble cardholder data that it becomes indistinguishable from cardholder data.
The issue of indistinguishable vs. distinguishable data arises due to the specific formatting scheme implemented by the solution. It is perfectly feasible to honor enough formatting constraints (i.e. matching lengths first 6 digits, last 4 digits, and passing the Luhn test) to produce cryptograms that can be reasonably confused with PAN. In fact such solutions will occasionally produce collisions with real PAN which cannot be prevented. Distinguishability can be achieved by relaxing any of the formatting constraints or adding additional markers provides suitable mechanisms
This article will focus exclusively on the use of FPE under PCI DSS and will use examples with primary account numbers (PAN) although it can equally be applied to other cardholder and sensitive authentication data. The following table illustrates some possibilities using a fictional PAN (starting with 8).
Formatting Preserved / Notes
812345 888888 6780
812345 218292 6780
Preserves length, first 6, last 4, and Luhn
T 812345 743604 6780
Preserves length, first 6, last 4, and Luhn. Adds a prefix marker.
021104 175178 6780
Preserves length, last 4, and Luhn.
167193 320527 6780
Preserves length and last 4.
812345 74793105 6780
Preserves first 6, last 4, and Luhn. Increases length.
812345 385184 6780
Preserves length, first 6, last 4. Luhn is off by a known amount.
812345 a2G3kq 6780
Preserves length, first 6, last 4. Alphanumeric middle.
As there is the potential that FPE solutions may require modifications to intermediate systems to accommodate distinguishable formats, FPE solution providers may need to offer a range of alternatives to their customers.
Both of these documents make the point that the users of these systems need to be able to tell the difference between PAN and tokens. The list of reasons includes:
Identifying malfunctions of the solution (i.e. failure to transform the data)
Ensuring important data is identified so that it can be adequately protected (i.e. scoping errors)
The table below illustrates key recommendations from both these documents.
Vendor needs to provide a guidance document, e.g. a Tokenization Implementation Guide (TIG) ,to ensure that the solution can be securely implemented.
YES (i.e. a TIG)
Vendor needs to provide a method or tool to facilitate distinguishing PAN from token
Provide guidance on probability and limits to an attacker guessing PAN from a token
Examples show that fully format preserving tokens (i.e. length, first 6 digits, last 4, passing Luhn) are possible
Addresses Scope Implications of tokens and indicates that tokens may be out-of-scope for PCI DSS
Contains examples of PAN and Tokens
Responsibility for correct implementation rests with organization (e.g. merchant) and is part of their DSS (i.e.. either directly or through outsourcing)
As these documents are guidance and best practices rather than standards and requirements, the question of distinguishability is likely to foster considerable debate about what is actually needed. And while distinguishability may not be theoretically required at this point in time, we expect that it will be a practical requirement. Because organizations using these solutions will need agreement from their assessors on the scope of their DSS assessments, any organizations that implement tokens or cryptograms that are indistinguishable from PAN may find this data will be in-scope for PCI DSS. The practical reality of this guidance is that organizations wishing to implement format preserving technology will need to perform suitable due diligence on their solution choices and also that solution providers will need to ensure that they can support their customers. Specifically, they will need to address the question of distinguishable FPE.