Version 3.1 of the PCI DSS standard drives better encryption
The PCI DSS v3.0 card payment security standard is being phased out and the new PCI DSS v3.1 standard is valid from 15th April, 2015 and mandatory after 30th June, 2016.
In practice the transition will begin over the next couple of weeks, as soon as the PCI Security Standards Council (PCI SSC) publishes the new reporting templates and the QSA companies start using them.
Why a new version of the standard?
In short, the PCI SSC has discovered that because of vulnerabilities such as POODLE and BEAST, the old cryptographic protocols are not as secure as they were once thought to be. The PCI SSC has stated that the SSL v3 version is no longer safe and must not be used. It has also specified, that the TLS v1.0 version should not be used and the TLS v1.1 may be used with certain restrictions. These findings have led to the publication of a new version of the PCI DSS standard. Naturally, the new versions also include a number of other adjustments and corrections. These other changes are not very significant and will not be discussed in this posting.
What's different?
The versions SSL v3, TLS v1.0 and TLS v1.1 are not to be used with new solutions, according to a directive that came into effect on15th April, 2015. From June of next year, use of these protocols with existing solutions will also be prohibited.
To make the matter a little less clear-cut, the TLS 1.1 version may be used with certain restrictions (see NIST SP 800-52 rev1 for more information about the use of TLS v1.1). If it can be verified that the SSL v3.0 and TLS v1.0/v1.1 versions are secure on a certain payment terminal, these protocols can be used with that terminal even after June 2016. However, this requires proof of security. I recommend updating payment terminals whenever possible, because providing proof of security can in practice be very difficult and costly.
It can't be said that the situation is too “easy” from a security point of view either, because the PCI SSC hasn't yet commented on the vulnerability of the TLS v1.1- and v1.2 protocols regarding CBC encryption (Cipher Block Chaining). The institute does, however, strongly recommend that only the TLS v1.2 version be used.
In my opinion, the safest option is to exclusively use the TLS v1.2 protocol and certain encryption methods (Cipher Suites) such as:
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
However, this will cause some problems, because not all browsers support the TLS v1.2 version by default. This is an issue with older browsers particularly. For example, in practice we must allow continued support for TLS v1.0 if we want to use IE9 with default settings in a Windows Vista environment or continue using older Android browsers. All the newest browsers support TLS v1.2, but in real life people don't always use the newest browsers and devices. This is one of the reasons the PCI SSC has made it compulsory to provide a risk mitigation analysis and plan detailing the reasons for not adopting a secure protocol version. As mentioned above, for justifiable reasons the transition can be postponed until 30th June, 2016.
In machine-to-machine communication (M2M) I see no reason not to use TLS v1.2 and the above-mentioned encryption methods exclusively, provided they are supported, of course. It's also good to remember to block the use of other, weaker protocol versions in the settings. And it's a good idea to use RSA tokens that are long enough along with a secure compression function; 4096 bits is, in my opinion, a good length for an RSA token and SHA-256 works well as a hash.
To sum it up, one should always use cryptographic protocols that are known to be secure. However, we should be prepared, now and in the future, for the fact that these recommendations change as our understanding grows.
If you are still unclear about cryptographic protocols and protocol versions, we'll gladly help you getter a better grip on the topic, regardless of whether or not your organisation follows PCI DSS standards.
For more information see:
Migrating from SSL and Early TLS [.pdf]
Lehdistötiedote: PCI Council publishes revision to PCI data security standard [.pdf]
PCI DSS Summary of Changes v3.0 to v3.1 [.pdf] *)
PCI DSS v3.1 -dokumentti [.pdf] *)
Raymii.org (Remy van Elst): Strong SSL Security on Apache2
Qualys: SSL/TLS Deployment Best Practices
Mozilla Wiki: Security/Server Side TLS
BlueKrypt: Keylength – Cryptographic Key Length Recommendation
*) downloading requires acceptance of license