Securing PAN Using Keyed Cryptographic Hashing in PCI DSS v4.0.1

Securing PAN Using Keyed Cryptographic Hashing in PCI DSS v4.0.1

The following three words, “keyed”, “cryptographic”, and “hashing” are sure to raise the anxiety levels for professionals working on PCI DSS v4.0.1, where hashing is used to render PAN unreadable. The introduction of keyed cryptographic hashing in Requirement 3.5.1.1, which becomes mandatory on March 31, 2025, will make these three words come to life, very directly.

However, implementing keyed cryptographic hashing need not be an angst invoking experience, and once understood, the value of adding a key to the hashing process will readily apparent.

In this article, we will demystify the process of hashing, identify where hashing may be inappropriate, and explain how keyed cryptographic hashing works to secure PANs.

What is Hashing?

Hashing is a cryptographic process that transforms of any length into a fixed-length output (the “hash value”) using a mathematical function. This transformation enables verification of data integrity without exposing the original data.

A hash function slices, shifts, and reorders data through multiple iterative loops, so that the hash value is unique to the input and cannot be reversed. Not being reversable, hashing does not use encryption/decryption keys, and the strength of the hashing function lies in the incredibly large number of possible hash values that could be the result of an input value.

Hashing is a one-way process that cannot be reversed.

Hashes are used in password verification (by comparing a stored hash of a password, against the submitted hash of the password), file integrity monitoring by comparing expected and in-place file hashes, and for payment card authentication (comparing a stored hash of a PAN against a submitted hash of a PAN). In all these cases, the hash value is sed to verify authenticity without revealing the original secret.

Comparison of the hashes without revealing the PAN

The strength of the hashing function is dependent on a few key properties:

1. Hash functions should produce unique hash values, given unique input data. This property is referred to as “collision resistance”.
2. Hash functions should be one-way transformations so that the knowledge of the hash does not allow an attacker to transform it back to the original input data.
3. Hash functions should not lend themselves to simple brute-force hash calculation (or pre-calculatable into look-up tables) using likely input values ranges, for example 8-character passwords, or 16-digit PANs.

The strength of hashing function is tied to the algorithm and hash length, where strong hash functions such as SHA-256 and SHA-3 provide a robust algorithm and sufficient hash size.

The Problem with Hashing PAN Values

While strong hashing functions may prevent the exposure of sensitive input data such as pass-phrases that use sufficiently long input strings made up of many types of characters (upper case, lower case, digits, and special characters), some types of input data do not lend themselves to secure hashing, regardless of the strength of the hashing algorithm.

Consider the following exaggerated example of a single lower-case letter of the alphabet used to create a password (pass-letter ☹). While a strong hashing function may produce a long hash that cannot be reversed back to the original single letter, it’s a trivial exercise to brute-force check all possible one-character passwords (of which there are only 26 possibilities) and compare the hashes to the password hash. Adding a “salt value” to the password does not increase the brute force difficulty, since salt values are intended to prevent pre-calculation of the hash (in large hashing tables). Salt values are not secret, and for simple inputs add no difficulty to brute forcing the hash.

While the example of a single character password may seem overly simplified, PAN values are usually limited to 16 digits, 6 or 8 of which are BIN values, and the last 4 of which are known, leaving only 6 to 10 digits to brute force, including a calculated Luhn check digit value.

Modern computers fitted with high performance GPUs can calculate multiple billions (or trillions) of hashes per second, finding every PAN hash in a fraction of a second. The small range of PAN values permits an attacker to quickly brute force all combinations of values in discovering a hash that matches, even where a salt value is added.

Would you like to dive deeper into how these apply to your business?

To see a practical real-world use case of why even salted hashes are insecure when used to secure small (low entropy) data such as PANs, see the Control Gap blog post, How a $1200 Graphics Card Threatens Your PCI DSS Compliance and Security.

Keyed Cryptographic Hashes

Keyed cryptographic hashes address the problem of small input space by incorporating a secret key into the hashing process. While simply adding a secret key value to the input might be sufficient, a robust keying process involves a series of key additions and multiple intermediate hashes. This process ensures that the final hash varies sufficiently, regardless of the length and complexity of the input data.

There are different keyed cryptographic hashing algorithms that are suggested as being appropriate for use in the guidance section of PCI DSS v4.0 Requirement 3.5.1.1, including HMAC, CMAC, and GMAC, with an effective cryptographic strength of at least 128-bits.

Let’s have a look at a simplified example of a keyed cryptographic hash (HMAC) and how keying is applied to the hashing process.

1. Prepend a secret key to the data (in our case, PAN) to be hashed.

   Key+PAN 

3. Hash the entire value.

   Hash Function (Key+PAN) = Hash1

4. Prepend the key again to the hashed value.

   Key+Hash1

3. Hash the entire value again.
   

   Hash Function (Key+Hash1) = Final Hash

And that’s it!

An actual implementation of this method will add padding to ensure that the keys are the proper block size, but otherwise, it’s that easy.

The PAN is secured by the key without additional cryptography, requiring only secure key management. A keyed cryptographic hash prevents secret exposure while validating its value, even for small secrets like a PAN. Its strength lies in irreversibility, with the key preventing brute force attacks on small secrets.

To discuss hashing or any other PCI DSS requirements, CONTACT US.