PCI DSS 3.7.1: Key-management policies and procedures are implemented to include generation of strong

PCI DSS v4.0.1 control 3.7.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 3.7.

Requirement 3: Protect Stored Account Data › Section 3.7

Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data.

Summary

Generate cryptographic keys strongly, and write down how you do it.

What the assessor will examine

These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.

Procedure
3.7.1.a Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define generation of strong cryptographic keys.
3.7.1.b Observe the method for generating keys to verify that strong keys are generated.

The first of the nine controls in section 3.7, which is the lifecycle 3.6.1 points at and the price of choosing encryption at 3.5.1 rather than truncation or tokenisation. Generation is where the whole chain is decided: a key generated from a weak source cannot be rescued by good storage, rotation or custody afterwards. Both procedures are about the documented process as well as the practice, so "the library does it" is only half an answer: the policy has to say what strong generation means for you.

What to prepare

  • The key-management policy covering generation, with the algorithms and strengths.
  • Evidence of the generation mechanism: an HSM, a key management service, or a named library and its entropy source.
  • Records for keys currently in use, showing how each was generated.

How to implement it

1. Generate inside the boundary that will hold the key. An HSM or key management service that generates and never exports removes most of section 3.7 at a stroke, because the key has no lifecycle outside it.

2. Name the source of randomness. "Strong" is a property of the entropy as much as the algorithm, and a key generated from a seeded pseudo-random source on a freshly booted virtual machine is the classic weakness.

3. Write the policy even where the platform does the work. Both procedures examine documentation; a correct implementation with nothing describing it fails the first half.

4. Do not generate keys in application code by default. It puts the key in memory, in logs if anything goes wrong, and in whatever the process writes.

Where this commonly fails

  • Keys generated by application code with an unspecified randomness source.
  • A correct mechanism with no documented policy behind it.
  • Key strength chosen once and never revisited against current guidance.
  • Generation handled well while the rest of section 3.7 has no owner.

Others in section 3.7:

Control What it requires
3.7.2 Key-management policies and procedures are implemented to include secure distribution…
3.7.3 Key-management policies and procedures are implemented to include secure storage…
3.7.4 Key management policies and procedures are implemented for cryptographic key changes for keys…
3.7.5 Key management policies procedures are implemented to include the retirement, replacement…
3.7.6 Where manual cleartext cryptographic key-management operations are performed by personnel…
3.7.7 Key management policies and procedures are implemented to include the prevention…
3.7.8 Key management policies and procedures are implemented to include that cryptographic key…
3.7.9 Service providers: Where a service provider shares cryptographic keys with its customers for transmission…

3.6.1.4 · All controls · 3.7.2

Source

The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.

The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.