On June 30th 2018, new Payment Card Industry Data Security Standard requirements (PCI-DSS) go into effect. This means that payment card acquirers, processors, gateways and services providers worldwide are working to implement more secure encryption protocols for transactions.
The industry is required to discontinue the use of Secure Sockets Layer and early versions of Transport Layer Security, and implement, instead, a more secure encryption protocol – TLS v1.1 or higher (see: Date Change for Migrating from SSL and Early TLS) .
TLS is a cryptographic protocol used to establish a secure communications channel between two systems. It’s used to authenticate one or both systems and protect the confidentiality and integrity of information that passes between the systems.
“To safeguard payment data in accordance with PCI-DSS, it is critically important that organizations upgrade to TLS v1.1 or higher as soon as possible and disable any fallback to SSL/early TLS,” says Jeremy King, international director of the PCI Security Standards Council.
“Because of its widespread use online, SSL/early TLS has been targeted by security researchers and attackers,” King says. “Many serious vulnerabilities in SSL/early TLS (e.g. POODLE, BEAST, CRIME and Heartbleed) have been uncovered over the past 20 years, making it an unsafe method for protecting sensitive data.
“If left unaddressed, these serious vulnerabilities in SSL and early TLS that put organizations at risk of being breached. The widespread POODLE and BEAST exploits are just a couple examples of how attackers have taken advantage of weaknesses in SSL and early TLS to compromise organizations.”
The PCI-DSS protocol migration date applies to all environments except payment terminals – and the SSL/TLS termination points to which they connect – that can be verified as not being susceptible to any known exploits for SSL and early TLS.
“POIs [points of interaction] are currently not as susceptible to the same known vulnerabilities as browser-based systems,” the PCI Council notes in a blog about the June 30 deadline. “Therefore, after June 30, 2018, POI devices (and the termination points to which they connect) that can be verified as not being susceptible to any of the known exploits for SSL and early versions of TLS may continue to use SSL/early TLS. If SSL/early TLS is used, the POIs and their termination points must have up-to-date patches, and ensure only the necessary extensions are enabled.”
Singapore-based Tom Wills , director of Ontrack Advisories, a banking and payments consultancy, notes that the exception for certain payment terminals has stringent conditions.
“The POIs and their connected termination points have to be demonstrated not to be susceptible to any known vulnerabilities in the earlier versions of TLS and SSL,” Wills says. “They have to be kept patched. Unnecessary extensions have to be disabled. And they can’t make use of weak cipher suites or unapproved algorithms like RC4 and MD5.”
Wills says organizations that are required to comply with PCI-DSS will be subject to the standard penalties for noncompliance.
The card brands, including VISA and MasterCard, can fine banks (acquirers) for noncompliance by the acquirer’s merchants from $5,000 to $100,000 per month, plus additional liabilities in the event of a data breach, including further fines and suspension of payment card acceptance privileges, Wills explains. The acquirer can choose to turn around and pass the fine on to the merchant.
“On a strictly security level, if a breach can be traced to a failure to upgrade to the new TLS versions, the consequences of any breach will apply: possible reputational damage, customer service and notification costs related to responding to the incident, and so on,” Wills adds.
And Leach says those who fail to migrate to new protocols risk the loss of confidentiality or integrity of data as well as the loss of cryptographic keys.
Securing with New Protocols
According to the Open Web Application Security Project, or OWASP, the primary benefit of transport layer security is the protection of web application data from unauthorized disclosure and modification when it is transmitted between clients (web browsers) and the web application server, and between the web application server and back-end and other non-browser based enterprise components.
“The improved security in newer TLS versions lies in adjustment of numerous features at the detail level, such as, for example, replacing obsolete cryptographic suites with newer and more secure ones and gives more flexibility,” Wills explains.
Major changes in TLS 1.1, compared with earlier versions, include:
- The Implicit Initialization Vector is replaced with an explicit IV to protect against cipher block chaining attacks
- Handling of padded errors is changed to use the badrecord_mac alert rather than the decryption_failed alert to protect against Cipher Block Chaining attacks
- Internet Assigned Numbers Authority registries are defined for protocol parameters
- Premature closes no longer cause a session to be non-resumable.