NIST & FIPS Considerations for EMV Tokenization

In this article, we will review some of the constraints of an EMV tokenization solution when it comes to FIPS and more generally, NIST considerations.

A Quick Reminder about FIPS

Here are some quick facts about FIPS:

• The Federal Information Processing Standards (FIPS) is a set of public standards released by the federal government of the United States that aims to create a standard for the use of computer systems in a civilian context;
• FIPS is overseen by the National Institute of Standards and Technology (NIST);
• Several FIPS standards control the use of cryptographic systems, for example, FIPS-140-2 dictates the standards for building cryptographic modules and HSMs;
• FIPS-140-2 offers four levels of validation. At the highest level (Level 4), the physical mechanisms of security should provide complete protection of the cryptographic module with the goal of detecting all unauthorized attempts at physical access;
• FIPS-140-2 certification is done via the Cryptographic Module Validation Program (CMVP).

FIPS 140-2 Level 3 Random Number Generators and Token generation

One usually considers that a safe token is truly random and has no possible link to the original value it represents. The Payment Card Industry (PCI) Council has issued several guidelines and constraints regarding token randomization.

NIST has certifications for FIPS 140-2 Level 3 Random Number Generators. They can help guarantee a token’s uniqueness since that standard is mainly prevalent in HSMs.

Following PCI recommendations, “The tokenization method should be shown to act as a family of random permutations from the space of actual Primary Account Numbers (PANs) to the token space.” Such a family of random permutations should follow the FIPS 140-2 Level 3 Random Number Generators standards.

Additionally, since PAN data are made of digits, in the case of generating “like-for-like” PAN tokens, SP 800-90A Rev. 1 (Recommendation for Random Number Generation Using Deterministic Random Bit Generators) may still be a good choice, according to the PCI guidelines,

NIST 800-38G and Format Preserving Encryption for Tokens

Format preserving encryption (FPE) is a technique widely used by token generator platforms. Obviously, FPE is a challenge because the output space will not have the same size than the input space. For instance, if we consider 16-digit credit card numbers (PANs), the output space will have a size of 10^16. That is to say “around” 32 bits, which might not be large enough.

NIST 800-38G details how to perform FPE by specifying three methods for FPE. The “FFX” methods are respectively called FF1, FF2, and FF3. Each one is a mode of operation of AES, which is used to construct a round function within the Feistel structure for encryption.

FF3 is no longer suitable because, in 2017, a cryptanalytic attack was discovered. FF1 is still supposed to be secure. However, with the payment card data use case, there may be not enough entropy to create enough output without a significant risk that it could be reversed.

Tokenization platforms for banking are involved with PCI certification and usually have to comply with NIST 800-38G and other standards. Only one method is available, namely FF1, which is under high scrutiny and eventually this will increase certification costs as well.

Tokenization platforms using FF2 or FF3 won’t be NIST-certified.

Token Vaults Should Be Using a FIPS-140-2 certified HSM

In most cases, the card token vault should be using an HSM that is FIPS-140-2 (level3) certified because the PCI Council explicitly recommends: “If hardware products are used for tokenization, the hardware products should be validated to FIPS 140-2 Level 3” ^[1].

Here we list several card data vault providers and whether they use a FIPS-140-2 Level 3 HSM.

Note that these are card data vault providers, not the tokenization software service that eventually works in combination with other hardware solutions, including  FIPS-140-2 Level 3 HSMs such as nCipher or Utimaco HSMs.

Using Hashes for Token Generation and NIST 800-131a

To avoid dictionary attacks, a cryptographic salt should be added to the token generation by using a hash function to increase security. However, VISA recommends using the same salt per merchant for multi-use token and mentions that the minimal size for the salt should be 64 bits ^[2].

Following NIST 800-131a, cryptographic salts should be at least 80 bits in size. Therefore, tokens generated by using hashes should follow NIST’s additional requirements and consider a minimal cryptographic salt of 80 bits.

Conclusion

We saw that FIPS and NIST often add extra security requirements when it comes to tokenization and token generation. Currently, since there are no ‘global’ standard for tokenization, it is a wise choice to make sure that tokenization platforms respect NIST’s requirements, even if such requirements are not always mandatory when it comes to PCI-DSS or EMV validation.