Key management in PCI DSS 1.2

The Payment Card Industry Data Security Standard (PCI DSS) version 1.2 came out in October 1, 2008. It has a few changes from the earlier 1.1 version, but one of them seemed worth of mentioning. This particular change is actually in the glossary, where "strong cryptography" is defined.

Here's how "strong cryptography" is defined in PCI DSS v1.1:

General term to indicate cryptography that is extremely resilient to cryptanalysis. That is, given the cryptographic method (algorithm or protocol), the cryptographic key or protected data is not exposed. The strength relies on the cryptographic key used. Effective size of the key should meet the minimum key size of comparable strengths recommendations. One reference for minimum comparable strength notion is NIST Special Publication 800-57, August, 2005 ( or others that meet the following minimum comparable key bit security:

• 80 bits for secret key based systems (for example TDES)

• 1024 bits modulus for public key algorithms based on the factorization (for example, RSA)

• 1024 bits for the discrete logarithm (for example, Diffie-Hellman) with a minimum 160 bits size of a large subgroup (for example, DSA)

• 160 bits for elliptic curve cryptography (for example, ECDSA)

Here's how "strong cryptography" is defined in PCI DSS v1.2;

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).

See NIST Special Publication 800-57 ( for more information.

It's interesting to see that proper key management practices are now part of the definition. I have to wonder why this was added. It might have been an oversight in the earlier version. It's easy to overlook things when you're writing, and the people who wrote the earlier versions of the PCI DSS might have just forgotten to include it.

It might be part of a conscious effort to gradually make the PCI DSS more and more stringent with each version. That might be the PCI Security Standards Council's way of getting the payment card industry to continue to improve over time.

A third possibility is that it's in reaction to merchants or banks that tried to be minimally compliant with PCI DSS v1.1 by using encryption but having sloppy key management practices. Sound key management can be expensive, so it's certainly possible that people tried to do this. I've seen it happen on more than one occasion myself. It's hard to say what the exact reason for this change was, but I'd bet on the last reason: that people tried to be minimally compliant with PCI DSS and ended up with solutions that really didn't provide any additional security but managed to technically comply with the standard.

Leave a Reply

Your email address will not be published. Required fields are marked *