How to address the common stumbling blocks of your PCI Assessment – Encryption

Part 1 – Encryption

Properly meeting the encryption related requirements for the PCI DSS can be one of the most challenging areas for many organizations. We will be reviewing specific challenging encryption requirements and breaking them down to help clarify what is really intended by each requirement and what are some possible approaches to meet the requirements.

PCI DSS Requirement:

3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.

PCI DSS Testing Procedure:

3.5.2 Examine system configuration files to verify that keys are stored in
encrypted format and that key encrypting keys are stored separately from data encrypting
keys.

Intent:

The intent of this requirement is to ensure that encryption keys are not stored together
so that in the event of a system compromise, decrypting cardholder data will be more
difficult or ideally impossible.

Possible Solutions:

One of the most challenging aspects of this requirement is the definition of “separately.”
Does this mean separate physical systems? Separate areas or forms on the same system?
The best practice would be to have your keys stored on separate systems thereby ensuring
that the compromise of a single system will not result in the full compromise of cardholder
data. Ultimately, your PCI Assessor will have to make the final call.

PCI DSS Requirement:

3.6.1 Generation of strong cryptographic keys

PCI DSS Testing Procedure:

3.6.1 Verify that key-management procedures are implemented to require the
generation of strong keys.

 

 

Intent:

PCI DSS defines strong cryptography as follows:

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).

The intent is to ensure encryption keys are created utilizing an industry accepted
process and algorithm/bit length.

Possible Solutions:

The most common symmetric key encryption algorithms and length are AES 128/256 bit
and TDES two-key (112 bit) or three key (168 bit). Common Asymmetric key encryption
algorithms and length are RSA 1024/2048 bit.

It
is important to not only use an accepted encryption algorithm and key length, but
also to ensure that the keys are generated in a strong fashion. Generally accepted
methods of strong encryption key generation include the use of pseudo-random data
of high entropy. The end result should ensure that encryption keys are not “repeatable”.
To clarify, the exact same encryption key should not be able to be generated twice.

PCI DSS Requirement:

3.6.6 Split knowledge and establishment of dual control of cryptographic keys

PCI DSS Testing Procedure:

3.6.6 Verify that key-management procedures are implemented to require split
knowledge and dual control of keys (for example, requiring two or three people, each
knowing only their own part of the key, to reconstruct the whole key).

Intent:

The primary intent of 3.6.6 is to ensure that no single person has access to a plaintext
encryption key.

Possible Solutions:

This requirement can be one of the hardest to achieve properly.

There are two general approaches for 3.6.6 from a high level.

First, work towards meeting the requirement as stated. Establishing dual control over
an encryption key requires that two or more individuals would be required to access
a complete plaintext encryption key. Split knowledge requires that no single person
has access to any bits of the encryption key that would convey knowledge of the resultant
encryption key.

Discussing your specific scenario with your PCI Assessor is often the best path toward
compliance.

The second approach is to work towards rendering this requirement “Not Applicable.”
The dual control and split knowledge all surround the exposure of a “plaintext” encryption
key. The usage of an HSM (Hardware Security Module) or payment application that does
not disclose a plaintext encryption key at any time would allow for this requirement
to be documented as “Not Applicable” as there is no encryption key for which to have
dual control over, or split knowledge of. In the PA-DSS (Payment Application Data
Security Standard), taking the approach of not disclosing plaintext encryption keys
has become increasingly common. This approach cannot only simplify how to meet these
complex requirements, but realistically also increases the overall security of the
application by taking the “human element” completely out of equation.

By having a good understanding of these common stumbling blocks, you can work towards getting in front of these issues and establishing a solid “plan of attack” to ensure your organization will continue heading on its path towards full PCI compliance.