PCI DSS v4.0 – The Most Important Changes at a Glance: Keyed Cryptographic Hashes

30. January 2024

Last updated: 30 January, 2024

On March 31, 2022, the Payment Card Industry Security Standards Council (PCI SSC) released version 4.0 of the PCI DSS - the most comprehensive update to the standard since version 1.0. To help you ease the transition, in our series of posts we take a closer look at the key new features that PCI DSS v.4.0 brings. In the fifth part, we look at the new requirement for keyed cryptographic hashes.

The PCI DSS prohibits the storage of PANs (Primary Account Numbers) in plain text, so that these sensitive credit card data cannot be read and misused by criminals even after a successful attack. Previous versions of PCI DSS recommended the use of salted hashes, as well as slow hash methods to protect PANs. The latest version 4.0 now requires hashes to be protected with a key.

Hashing Algorithms in Previous PCI DSS Versions

The previous versions of PCI DSS recommended the use of slow hashes and salted hashes to protect PAN.

The previous versions of the PCI DSS recommended the use of a string of random data - a salt - as additional input for a hash function to protect PAN. The goal of salting is to protect against dictionary attacks or attacks using a rainbow table, a data structure that allows a fast, memory-efficient search for the original string for a given hash value. However, if no secret salt is used, or if the salt has not been sufficiently protected, the corresponding data, for example the PAN, can be read from the attacker's previously calculated dictionaries or rainbow tables.

Slow hashes are designed to be inefficient and difficult to compute. A hash method used to secure data should be slow to better protect data against brute force attacks. The disadvantage of slow hash algorithms is their high computational memory intensityUse of slow hash procedures and salted hashes.

New PCS DSS Requirement: Keyed Cryptographic Hashes

The new requirement 3.5.1.1 in PCI DSS v4.0 calls for the use of hash algorithms that include a key. This is intended to prevent hashes from being back-calculated and PANs from being read by attackers.

Requirement 3.5.1.1

The requirement is "future-dated", i.e. not mandatory to implement until April 1, 2025.

3.5.1.1 Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.

Quelle: PCI DSS: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf

Which Hashes Does the Standard Recommend?

Suitable encrypted cryptographic hash algorithms named by PCI DSS v4.0 include: HMAC and KMAC with an effective cryptographic strength of at least 112 bits or CMAC and GMAC with 128 bits (NIST SP 800-131Ar2).

The PCI DSS references the National Institute of Standards and Technology (NIST) standard NIST SP 800-107 for further information and recommendations for hash algorithms.

How Keys Must Be Protected

To protect the keys used from disclosure and misuse, the management processes from requirements 3.6 and 3.7 must be applied to them.

These include the following measures:

  • Access to the keys is restricted as far as possible
  • The keys are stored in a secured system (e.g. HSM), or encrypted with a key with at least the same cryptographic strength, which is stored separately
  • The keys are part of an inventory which describes the algorithm used, key runtime, as well as the utilization

Requirement 3.7 also requires the definition of processes for the creation and subsequent secure distribution of strong keys.

Also interesting:

NIS-2 - Three Questions for our Experts on the New EU Directive

NIS-2 - Three Questions for our Experts on the New EU Directive

NIS-2: The new EU directive for cyber security is currently raising questions for security managers in countless companies: Are we affected? What requirements will we have to fulfil? What exactly do we know at this point? Dr. Marian Corbe, Chief Executive Officer at...

Categories

Categories