Encryption Types

[rx.jeff]

Would 128-bits RC4 algorithm suffice for encrypting the PAN? I don't recall seeing any guidance on this in the PA-DSS 1.2... I know that 3DES and AES are acceptable encryption "standards", however, I don't see any guidance on which is NOT acceptable.

Correct me if I'm wrong here.

Thanks!

[ADail]

What I am told is that it just has to be one of the encryption routines that has been validated by an approved lab.

[rx.jeff]

Originally Posted by ADail

What I am told is that it just has to be one of the encryption routines that has been validated by an approved lab.

So where can I find out about whether the algorithm is approved?

[jbhall56]

The National Institute of Standards and Technology (NIST) is who to look to for guidance in the United States (http://www.nist.gov).

Look at their Computer Security Resource Center and their Cryptographic Algorithm Object Registration page (http://csrc.nist.gov/groups/ST/crypt...lgorithms.html) for a list of approved cryptographic algorithms.

[MarkB]

This is another gray area. The PCI DSS does not mandate specific algorithms nor approval by NIST.

Specifically, PCI DSS provides guidance and best practice. For example, PCI DSS permits and references Blowfish, but that is not an approved NIST algorithm nor does it appear to be in a process of becoming one, nor is it a FIPS algorithm. Therefore FIPS approval alone cannot be used as a measure of the suitability of a cipher for PCI DSS. In particular, countries outside the US may be mandated to use non-FIPS ciphers, such as Camellia (standardized by the EU NESSIE project and Japan's CRYPTREC.)

Likewise, EU eSTREAM and ECRYPT standards as other sources of vetted cryptography, but are non NIST and non FIPS.

PCI DSS is a global compliance issue.

From the PCI DSS Glossary definition:

Approved Standards: Approved standards are standardized algorithms (like in ISO and ANSI) and well-known commercially available standards (like Blowfish) that meet the intent of strong cryptography. Examples of approved standards are AES (128 bits and higher), TDES (two or three independent keys), RSA (1024 bits) and ElGamal (1024 bits)

Strong Cryptography: 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 (http://csrc.nist.gov/publications/) 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)

On RC4's suitability:

In respect to the question- RC4, being a stream cipher, presents a number of implementation risks and will often yield insecure applications when not used with extreme care. There are also a number of attacks in the cryptographic literature that bring the strength of that technique into question.


Regards,
Mark

[ADail]

I think the commercially available comment is the key. The intent is that a company not use some internally developed encryption routine that has never been tested by people who know what they are doing, and do this sort of thing for a living.

[jbhall56]

You need to reference the PCI DSS Gloassary for the definition of 'Strong Cryptography'. It is defined as "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 (http://csrc.nist.gov/publications/) for more information."

This is where the reference to NIST comes from and the requirement for using 'industry-tested and accepted' comes from.

[MarkB]

interestingly:

https://www.pcisecuritystandards.org...glossary.shtml

Still points to the older definition (PCI DSS 1.1)

Even so, PCI DSS doesn't mandate - its gives guidance and best practice. Again I would stress that even if you are using a "Cryptography based on industry-tested and accepted algorithms" if your key management and systems management is not sound, then its not going to provide any kind of effectiveness, nor compliance to PCI DSS.

Sound judgment, best practice, and specific knowledge and expertise about what you are doing relative to encryption and key management, how you are doing it, and how policy is enforced will be critical in ensuring that your conversation with your QSA has a meaningful outcome.

Regards,
Mark

[jbhall56]

Find the current glossary (v1.2) at this link https://www.pcisecuritystandards.org...ing_docs.shtml

The requirement on using strong cryptography is not a suggestion or a best practice, it is a requirement. The Glossary defines what is acceptable and what is not acceptable as well as pointing readers to the NIST document for further reference of other potentially acceptable solutions.

We have a situation going on right now involving Feistal Finite Set Encryption Mode (http://forum.paymentsecuritypros.com...read.php?t=910). It has been submitted to NIST for assessment, but has not been approved by NIST. While it holds great promise, since it has not been recognized by NIST or another standards setting body as a strong encryption method, it cannot be used for meeting PCI compliance.

As you correctly point out, strong encryption is only as good as how it is implemented. Poorly selected keys and/or poor key management can defeat a strong algorithm every time.

[MarkB]

To be clear, my post was not suggesting "Strong Cryptography" as defined by PCI DSS was not a requirement, it clearly is.

My comment about PCI DSS "not mandating" referred to specific algorithms, otherwise this would mean PCI DSS would not be agnostic of technology vs requiring an appropriate compensating control that is - e.g. strong cryptography with appropriate and effective key management.

Regards,
Mark