Understanding TLS 1.3 Encryption and It’s Role in PCI DSS Compliance

Transport Layer Security (TLS) is a cryptographic protocol that encrypts data, authenticates connections, and protects the data in transmission. As time passes, new versions of TLS are released to strengthen defenses and maintain an advantage of the constantly evolving threat landscape. Understanding these updates is essential for anyone managing secure systems or handling sensitive data online.  

In this article, we will explore how over the past decade TLS has increased the security, performance, and handshake speed and efficiency from TLS 1.2 to 1.3. Ahead of diving into TLS 1.3 though, check out our other blog post explaining protocols and cipher suites for TLS 1.2 for an explanation on what exactly a TLS handshake is and how it functions.  

Relevant Key Encryption Terms 

For even more context before we detail the specifics of TLS 1.3 and its advancements since TLS 1.2, be sure to also familiarize yourself with the following key encryption terms which will be referenced throughout this post: 

• Cipher Suites: a combination of algorithms that define how data is securely exchanged between two systems over a network 
• Static Keys: encryption keys used over multiple connections 
• Ephemeral Keys: temporary encryption keys that are used for a single session and discarded afterwards 
• TLS Handshake: the process that two systems agree on how they will communicate securely by selecting a cipher suite and exchanging encrypted keys 
• Authenticated Encryption with Associated Data (AEAD): a form of encryption that not only encrypts the data but ensures its authenticity and integrity in a single operation 

Now that you're more familiar with key encryption terms and the definition of TLS 1.2 encryption and how it functions, let's dive into the latest version of the TLS protocol, TLS 1.3. 

New Encryption on the Block  

TLS was first released in 1999 and has been updated throughout the years as technology continues to improve. TLS 1.3 is the newest version of the TLS protocol, published in August 2018 to replace the older protocol TLS 1.2 that had been in place since 2008. Many companies have yet to incorporate TLS 1.3 because they either lack the required system compatibility or computing power, they aren't mandated by government or local laws, or they are simply unaware that they are still using weak protocols.  

While TLS 1.3 is not a requirement for PCI DSS compliance, moving to TLS 1.3 is a smart long-term move as it’s faster, more secure, and removes weak encryption methods to protect your cardholder data.  

TLS 1.2 vs. TLS 1.3: Key Differences 

There are some very important changes with the newest version of TLS, including a faster TLS handshake, stronger cipher suites, and improved forward secrecy to enhance security and performance:  

1. Faster TLS Handshake 

A TLS handshake facilitates secure connections by exchanging keys and verifying endpoints before encrypting data between a client and server. This handshake uses cipher suites to exchange, authenticate, encrypt, and confirm data integrity upon receipt of the data. A full handshake for TLS 1.2 required 300ms while TLS 1.3 has sped the process up to only requiring 200ms.  

In the TLS 1.2 authentication process, the steps to achieve the handshake consists of a multiple steps and round trips: 

1. A client sends a “client hello” message encoded with the cipher suites and a randomly generated value.  
2. The server responds with a “server hello,” and selects a cipher suite and sends its certificate.  
3. The client verifies the certificate and generates session keys.  
4. The process is repeated for multiple round trips to establish encryption. 

Through the advancements in technology over the years, TLS 1.3 has changed to a one round trip (1-RTT) instead of the two (2-RTT) required in TLS 1.2, significantly decreasing connection times. Another benefit of the newest version of TLS is 0-RTT resumption. Clients that have previously connected to the server can send data immediately without waiting for the handshake. This improvement reduces latency, enhances performance for users, and is especially beneficial for your high-traffic websites and mobile applications.  

2. Stronger Cipher Suites 

In TLS 1.2, cipher suites used a series of blocks to send and receive data between a client and a server. TLS 1.2 required key exchange and optional authentication, encryption algorithm, and message authentication depending on the level of security the transmission required. TLS 1.3 improves security by eliminating outdated and vulnerable cipher suites that were still supported in TLS 1.2. In TLS 1.2, weaker encryption algorithms like RC4 and 3DES were still available which created security risks. Whereas TLS 1.3 utilizes Authenticated Encryption with Associated Data (AEAD) algorithms like lAES-GCM and ChaCha20-Poly1305, which combine encryption and authentication into a single step.  

Additionally, TLS 1.3 removed the static Rivest-Shamir-Adleman (RSA) key exchange and static Diffie Helmen key exchange (ECDHE) which relied on the use of long-term encryption keys. These methods posed a security risk because if an attacker compromised the private key, they could decrypt all past and future communications. In TLS 1.3, only ephemeral Diffie-Hellman key exchange (ECDHE) is allowed, ensuring that each session has a unique temporary encryption key that is discarded after use.  

One of the issues with TLS 1.2 is the amount of combinations that can be used for the cipher suites. In TLS 1.3, only a small set of strong cipher suites are used.

For example, TLS 1.3 uses the following five main cipher suites:  

• TLS_AES_128_GCM_SHA256 
• TLS_AES_256_GCM_SHA384 
• TLS_CHACHA20_POLY1305_SHA256 
• TLS_AES_128_CCM_SHA256 
• TLS_AES_128_CCM_8_SHA256   

In TLS 1.3, all cipher suites begin with “TLS_,” because the older versions of TLS (like SSL) are depreciated. The second block of the cipher suite is the encryption algorithm, which provides strong encryption. The third block is the chosen encryption mode used to protect the data. The fourth block is the message authentication function that ensures integrity and verifies that the encrypted data has not been tampered with. See the following article for further details about the simplification of cipher suites. 

3. Mandatory Forward Secrecy 

TLS 1.3 mandates ephemeral key exchange (ECDHE), ensuring new session keys for every individual connection between a client and a server. This means that each connection is encrypted with a unique key that is discarded after a session ends. If an attacker gained access to a server using the key, they would be unable to access past communications because each session acts as a temporary access pass. This guarantees perfect forward secrecy (PFS).  

This means that even if an attacker compromises one session’s key, they cannot decrypt past or future communications. To put it simply, imagine you are at a hotel. Every guest receives a unique key only accessible to their room. If someone takes their key and returns to use it after their stay is over, it would no longer be valid as new keys are issued for every stay. This is how the ephemeral keys in TLS 1.3 work. Each session is assigned a new encryption key that cannot be reused after its intended use.  

TLS 1.2 allowed static and ephemeral keys. The problem with static keys was they remained valid across multiple sessions. If a hacker obtained a key, they could decrypt previous communications introducing significant risks. By enforcing only Diffie-Hellman key exchange (ECDHE), TLS 1.3 guarantees that the keys used for each session are unique for each session and cannot be reused.    

The Role of TLS 1.3 in PCI DSS Compliance 

While TLS 1.2 is still compliant with PCI for now, TLS 1.3 provides greater security and compliance for securing card holder data in transmission. As new threats emerge, it's best practice to monitor updates from trusted sources from PCI SSC for guidance on new recommendations for TLS 1.3. Staying up to date will ensure that your configuration is always aligned with the best security practices for protecting payment card data.  

If you’re ready to take the next step in your PCI DSS Validation journey, or you have questions about PCI compliance or the process, Schellman can help. Contact us today to learn more about our services and we’ll get back to you shortly. 

In the meantime, learn more about the intricacies of PCI DSS in our related articles which 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?