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:

ECDHE-RSA-AES256-GCM-SHA384

But what do all these letters and numbers mean?

Now it’s time to send data.

 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:

KRB5_WITH_3DES_EDE_CBC_SHA

RSA_WITH_NULL_MD5

RSA_EXPORT_WITH_RC4_40_MD5

RSA_WITH_3DES_EDE_CBC_SHA

DHE_DSS_WITH_DES_CBC_SHA

DH_RSA_WITH_AES_128_CBC_SHA

DHE_RSA_WITH_AES_256_CBC_SHA

RSA_WITH_NULL_SHA256

ECDH_ECDSA_WITH_AES_256_CBC_SHA

ECDH_ECDSA_WITH_AES_128_CBC_SHA256

ECDH_RSA_WITH_AES_256_GCM_SHA384

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.
• Authentication
  • 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:

Use:

• TLS v1.2 and 1.3
• RSA keys >= 2048 bits
• ECC keys >= 256 bits

Do Not Use/Support:

 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:

• What’s New in PCI DSS v4.0
• SAQ A vs. SAQ A-EP: What Options Do You Have?
• What is a "Significant Change" Within an Environment?