Update March 2018 You can read about how to test PCI-DSS Cryptography compliance with our Analyzer software, or check out the new PCI DSS version 3.2 requirements for cryptography.
Cryptography is sufficiently complex to make writing a single compliance document that ensures security impossible. There are nonetheless various industry compliance guidelines that try to ensure the biggest mistakes are avoided. The PCI-DSS standard, now in version v3.1, describes security requirements for processing electronic payments and includes some interesting crypto advice.
Algorithms and Key Lengths
First, PCI-DSS includes (in the glossary) a definition of “strong cryptography” that is required at various points in a compliant system:
“Cryptography based on industry-tested and accepted algorithms, along with strong key lengths (minimum 112-bits of effective key strength) and proper key-management practices. [..] At the time of publication, examples of industry-tested and accepted standards and algorithms include AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher). See NIST Special Publication 800-57 Part 1 (http://csrc.nist.gov/publications/) for more guidance on cryptographic key strengths and algorithms.”
The NIST document cited has been updated since the release of PCI-DSS 3.1, and supplemented by a note on transitioning algorithms and keylengths. But no matter, this paragraph gives us some examples of algorithm and keylength pairs that can be considered “PCI-DSS Compliant”. To find out what algorithms an application is using you can use something like our Java Crypto Tracer.
- UPDATED Jan 2016 Just a few days after we first posted this article, PCI announced a date change in sunsetting TLS 1.0 and SSLv3 – you now have until June 2018 rather than 2016 to move to minimum TLS 1.1
Since PCI-DSS covers a lot of Internet-based payments, guidance is given on the use of protocols:
“4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
– Only trusted keys and certificates are accepted.
– The protocol in use only supports secure versions or configurations.
– The encryption strength is appropriate for the encryption methodology in use.”
This is followed by an interesting addition, new to version 3.1 of PCI-DSS:
“Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016.”
What exactly is “early TLS”? A supplementary document provides clarification: TLS 1.0 will be considered non-compliant for PCI-DSS from June 30 2016 (and SSL v2 and v3 are already considered non-compliant).
This is interesting because while SSLv2 and SSLv3 are deprecated by the IETF (the body responsible for TLS, see RFC 6176 and RFC 7568), TLS 1.0 is not. However, there are good reasons for getting rid of it: TLS 1.0 is vulnerable to the BEAST attack. The only server-side mitigation is to use the RC4 cipher, which is itself weak. Modern browsers mitigate BEAST client-side, but it makes sense for PCI to phase it out server-side since they can’t control which browsers will be used to connect to payment sites, and in any case the server-side weakness in the protocol may have other exploits. Add this to the fact that TLS 1.2 has other security improvements and the case for deprecating v1.0 is clear.
So how is the Internet doing in getting rid of TLS 1.0? A quick look at SSL Pulse tells us that as of 3rd December 2015, 98.8% of the most popular websites support TLS 1.0. According to the 14th December 2015 zmap TLS scan at scans.io, for 19.8% of the Alexa top 1 million domains, TLS 1.0 is the highest version supported! Of course, only a small proportion of these sites accept credit card payment data, but with other standards likely to follow suit, it looks like 2016 will see a lot of TLS re-configuration work.