Protocols and Cipher Suites for PCI DSS Compliance with TLS v1.2
When it comes to payment card security, the secure exchange of data is a well-known security requirement. It should come as no surprise that, for compliance with the PCI DSS standard, you must define how you do that.
Typically, the TLS handshake is the exchange of secret keys to establish a secure connection. The format of this handshake doesn’t change—protocols set the stage for how to communicate while the cipher suites address how to encrypt the data.
But the details behind all this may vary, and as PCI DSS QSAs, we see confusion around this topic come up during most assessments. That’s why, in this article, we’re going to break down the relationship between protocols and cipher suites, what makes a cipher suite strong rather than weak, and what combination of elements you need to be PCI DSS compliant.
When you read a how-to manual, you expect it to progress linearly and be organized well—that’s the entire point of you being able to follow it. We’ll do the same as we explain how all these elements work together so that you can implement the strongest ones and achieve compliance.
Breaking Down the Elements Involved
The great thing about protocols and cipher suites is that they’re presented linearly. Think about it like this—if you were a mechanic asked to work on the new Ford Truck, you’d prefer clear, progressive instructions on the engine setup. Imagine finding out the manual features random chapters, diagrams scattered throughout, and entire sections in a foreign language—that wouldn’t be helpful.
But before we get into how these are presented, let’s get into the basic facets involved to make everything moving forward a little easier:
- Algorithm: A defined sequence of instructions to perform a computation. (Each of the following communication streams relies upon algorithms to establish the encryption and transmit the data.)
- Communication Protocol: A set of agreed-upon rules that two or more systems can use to convey information. Essentially, “when we talk, this is the format we will use.”
- Security Communication Protocol: (Usually shortened to security protocol) Specific protocol that applies cryptography to the exchange to prevent the exposure of data.
- Cipher: An encryption algorithm used to encrypt and decrypt data.
- Cipher Suites: A combination of a key exchange, authentication, encryption + block/stream cipher, and message authentication.
Now that things are defined, let’s dive a little deeper into each and explore how they work together.
How Do Protocols and Cipher Suites Work Together in Payment Security?
Recall how protocols themselves are just the way two systems agree to speak with one another.
Before they do that, the aforementioned TLS handshake has to begin with identifying each endpoint—the “client” reaches out to the “server” to confirm that the “server” can be reached. (Ever seen those “site not available” messages? That indicates the endpoint was unavailable.)
After the server and client acknowledge each other, it’s time to protect that data. The trouble is that older protocols—both communication and security—have security vulnerabilities that cannot be addressed and so they shouldn’t be used.
(With few exceptions, modern systems support the current and secure protocols (such as TLS v1.2 and 1.3), leaving little reason to maintain older ones.)
As previously defined, cipher suites are packages of details—ciphers—that define all of the necessary elements to correctly make encryption over TLS work. They’re the other half of the TLS handshake.
Example Cipher Suite
To understand how these two work together, you don’t need to know the specific details on how algorithms work or how data is broken into blocks for encryption—we’ll use color coding to demonstrate how the elements collaborate:
But what do all these letters and numbers mean?
Defines how the keys between two systems will be exchanged. (All encryption relies on keys.)
ECDHE (Elliptical Curve Diffie Helmen Ephemeral) is the one-time key that will be created for this connection and exchanged with the distant end.
Authentication or Digital Signature Algorithm
Identifies how the server (and sometimes client – or connecting system) will perform verification.
RSA (Rivest-Shamir-Adleman) is what’s used by both endpoints to confirm, “you are the endpoint I think you are.” This completes the TLS handshake—the two systems ‘trust’ each other.
Now it’s time to send data.
Encryption Algorithm and Block/Stream Cipher
Applied to the data being encrypted—almost always formatted as a combination of algorithm, strength, and block mode.
AES256-GCM (Advanced Encryption Standard: 256 bit – Galois/Counter Mode) is the algorithm applied, the size of the encryption key used (256 bits), and how that data is put into blocks for encryption/decryption (GCM method).
Used to perform integrity checks on the encrypted data.
Last, SHA384 (Secure Hashing Algorithm – 384-bit digest) is the process to take the previous parts of encryption data and confirm that this data was not tampered with.
Conceptually, this is how keys are exchanged, endpoints are authenticated, data is encrypted, and integrity over that data is performed.
Strong Cipher Suites vs. Weak Cipher Suites
All that being said, the ability to securely protect data has progressed since these concepts first came into use. Encryption algorithms created in the 1980s can be broken today and so are unreliable to protect data in transit. Given the multiple variants in cipher suite options, we will break some common ones down using the same color coding and why these are considered to be strong or weak:
Now, what not to use for strong cipher suites:
- Key Exchange
- KRB5, FORTEZZA, and others are old and do not provide strong protections when encrypting data—using them increases the likelihood of your being hacked.
- You may have noted that this was not in place for all of the above, which is a misstep in itself.
- But when you do implement this, don’t use EXPORT—it’s a remnant from the 1990s and is now considered weak.
- Encryption Algorithm
- This also was not always present above, as shown by NULL—that the data was not encrypted at all.
- Furthermore, weak encryption such as RC4 and 3DES will not provide sufficient protection over data
- Message Authentication
- MD5 was popular but is deprecated and should not be used.
- SHA (SHA1) is borderline and we recommend moving away from it.
Using Cipher Suites in PCI DSS Compliance
It’s another step forward knowing which elements should be avoided for strong security—the next one is knowing what combinations will comply with PCI DSS standards. During your assessment, two basic principles will be checked to start:
- If system defaults are in place
- If vendor recommendations are in place
Why? Out of the box, many systems support weak configurations because they establish a connection with the most ease. Similarly, vendor recommendations almost always lead to security concerns.
But if you take these steps, you should get across the finish line or, at the very least, close:
- TLS v1.2 and 1.3
- RSA keys >= 2048 bits
- ECC keys >= 256 bits
Do Not Use/Support:
SSL versions 2 and 3
TLS versions 1.0 and 1.1 (early)
Weak Endpoint Authentication
EXPORT (sometimes shown as EXP)
Weak Message Authentication
Moreover, we strongly encourage you to phase out:
- Encryption algorithm 3DES
- Message authentication SHA (SHA1)
All that being said, these recommendations will change as new threats emerge and new protections are created. As things progress, the following resources may also be of value:
- Mozilla’s Rolling Recommendations
- EMVco’s Documentation Repository
- OWASP Recommendations
- Microsoft Requirements
- Internet Engineering Task Force considerations
Next Steps for PCI Compliance
The relationship between protocols and cipher suites is essential for adequate payment security, but you’ll need to take care to not use outdated or weak elements when creating your sequences if you’re seeking PCI DSS compliance.
But with all this information in hand, you’re more ready to find and implement strong protocols and cipher suites to protect the data in your charge and pass your assessment. (But remember, this addresses TLS 1.2—in a future post, we will provide similar guidance on TLS v1.3.)
To learn more about the intricacies of PCI DSS, read our other articles that will deconstruct other important facets, including what’s changed with the release of the latest version of the standard:
About Sully Perella
Sully Perella is a Senior Manager at Schellman who leads the PIN and P2PE service lines. His focus also includes the Software Security Framework and 3-Domain Secure services. Having previously served as a networking, switching, computer systems, and cryptological operations technician in the Air Force, Sully now maintains multiple certifications within the payments space. Active within the payments community, he helps draft new payments standards and speaks globally on payment security.