SSL/TLS and the PCI DSS Requirement 4

April 15th, 2013 by

The Payment Card Industry Data Security Standard (PCI DSS) consists of 12 requirements which were developed to protect cardholder data. Requirement 4 is about encrypting cardholder data as it is transmitted across open, public networks. The intent of this requirement is to ensure sensitive information (which includes Sensitive Authentication Data (SAD) during the authorisation process) is not easily accessible by malicious individuals as it is transmitted over networks.

PCI DSS Sub-Requirements 4.1

The first sub-requirement, 4.1, mandates that strong cryptography and security protocols are used to safeguard sensitive cardholder data during transmission over open, public networks and gives as examples SSL/TLS, IPSec and SSH. Some protocol implementations such as SSL version 2.0 have documented vulnerabilities and should be avoided.

Strong cryptography definition

Strong cryptography is not defined in the PCI DSS standard, nor in navigating the PCI DSS document. In the glossary for the PCI DSS, strong cryptography is defined as:

“Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).”

The glossary also refers the reader to the NIST Special Publication 800-57 for additional information which is provided in three parts. The glossary contains recommendations for key management, covering general concepts, best practices for key management organisation and application-specific key management guidance.

SSL/TLS Protocols

The SSL/TLS protocols are used by the HTTPS protocol to encrypt web pages and the data entered into them. There are a number of versions of SSL/TLS which are in use; SSL was developed by Netscape for transmitting private documents via the Internet. TLS was developed by the Internet Engineering Task Force (IETF) to provide similar functionality to SSL.

  • SSLv1 – Never Published
  • SSLv2 – released in February 1995
  • SSLv3 – released in 1996 (RFC 6101, Historical document)
  • TLSv1.0 – released in January 1999 (RFC 2246)
  • TLSv1.1 – released in April 2006 (RFC 4346)
  • TLSv1.2 – released in August 2008 (RFC 5246)

Both SSL and TLS use cryptographic systems to encrypt data, the actual cryptographic system used is negotiated during the SSL/TLS handshake where the cipher suite is selected and encryption keys are generated and exchanged. Both use the asymmetric encryption using the website certificate to exchange the private keys for symmetric encryption.

In order for SSL/TLS to be acceptable for the encryption of cardholder data to comply with the requirement 4 of the PCI DSS, the negotiation phase should result in the use of a strong cipher. This requires the server to support versions of SSL and TLS that do not have well known vulnerabilities and use cipher suites based on strong cryptography. The capabilities of a server using HTTPS are advertised by the certificate and the initial phase of negotiating the key exchange.

Vulnerability assessment tools

Vulnerability assessment tools that assess the security profile of servers using SSL/TLS will integrate the server to assess its capabilities and will attempt to connect using all versions of SSL and TLS and a range of ciphers from the weak to the strongest. If the tool supports a PCI DSS test mode it will report if the server is secure to the requirements of the standard. However even without a specific PCI DSS test for secure servers, the tools will report the capabilities of the server which can be examined to see if the requirements of the standard are being met.

IT Governance Solutions

IT Governance can help organisations access its infrastructure to verify if they are meeting the requirements of the PCI DSS and are using strong cryptography by using a scanning software service.

There are also a number of training options available from IT Governance such as the PCI Foundation and PCI Implementation & Maintenance training courses. These courses are led by PCI experts and are particularly useful if you are responsible for ensuring your organisation becomes compliant with the standard.


%d bloggers like this: