Authentication , Compliance , Encryption

Is Payments Industry Ready for New Encryption Protocols?

PCI-DSS Requirement Looms on June 30
Is Payments Industry Ready for New Encryption Protocols?

To meet new Payment Card Industry Data Security Standard requirements that go into effect June 30, payment card acquirers, processors, gateways and services providers worldwide are working to implement more secure encryption protocols for transactions. They're 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) .

See Also: Matching Application Security to Business Needs

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 (See PCI Council Extends Encryption Deadline) .

"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."

Playing Catch-Up

Sriram Natarajan, chief operating officer and former chief risk officer at Quattro, an Indian-based outsourcer that serves banks, notes: "With increased sophistication of online transactions, payments have to catch up, too. And as a majority of online payments are now on the mobile/in-app payments, the traditional PCI-DSS standards have to be suitably upgraded.

"New initiatives, such as EMV Three-Domain Secure (3DS), a messaging protocol to enable consumers to authenticate themselves with their card issuer when making card-not-present e-commerce purchases, are not possible on the old SSL standards," he explains.

The Migration Details

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, says Troy Leach, CTO of the PCI DSS Council.

"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."

Potential Penalties

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.

Dr. N. Rajendran, chief technology officer at National Payments Corp. of India, which is migrating to the new TLS protocol, notes: "The challenge for most organizations is to migrate their legacy systems to a new protocol; the entire process is ... investment intensive."

But Tim Sloane, vice president of payments innovation at Mercator Advisory Group, points out: "It would be a sad commentary if acquirers are almost a year behind Salesforce.Com and others in upgrading to the more secure TLS 1.1 or higher. If acquirers or merchants haven't already deployed, or at minimum haven't got a plan to deploy, TLS1.1 or higher, then they have been asleep at the security switch and don't deserve to receive PCI compliance."

Adds Julie Conroy, research director at Aite Group: "While we've known about this deadline since 2015, there are always laggards around various aspects of PCI compliance, and this is no exception. The problem of merchants running behind on security has been compounded as so many micro-merchants have come into existence over the past few years. Most of them believe they're too small to be on hackers' radar; they do not know that automation of attacks makes everyone a target."

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, Wills says, 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.

Immediate Action Steps

King says that if organizations continue to use SSL or earlier TLS as a security control in their new implementations, they need to have a formal risk mitigation in place.

"The new vulnerabilities could emerge at any time, and it is up to the organization to remain up to date with vulnerability trends and determine whether or not they are susceptible to any known exploits," he says.

Some suggested steps for entities to plan their migration to the new form of encryption include:

  • Identify all system components and data flows relying on and/or supporting the vulnerable protocols;
  • For each system component or data flow, identify the business and/or technical need for using the vulnerable protocol;
  • Immediately remove or disable all instances of vulnerable protocols that do not have a supporting business or technical need;
  • Identify technologies to replace the vulnerable protocols and document secure configurations to be implemented;
  • Document a migration project plan outlining steps and timeframes for updates;
  • Implement risk reduction controls to help reduce susceptibility to known exploits until the vulnerable protocols are removed from the environment;
  • Perform migrations and follow change control procedures to ensure system updates are tested and authorized

"This requires complete system overhauling, as all the critical systems, applications and OS also need to migrate to new protocols to comply with the new standards," Rajendran says.

Nick Holland, ISMG's director of banking and payments, contributed to this story.


About the Author

Geetha Nandikotkur

Geetha Nandikotkur

Managing Editor, Asia & the Middle East, ISMG

Nandikotkur is an award-winning journalist with over 20 years' experience in newspapers, audio-visual media, magazines and research. She has an understanding of technology and business journalism, and has moderated several roundtables and conferences, in addition to leading mentoring programs for the IT community. Prior to joining ISMG, Nandikotkur worked for 9.9 Media as a Group Editor for CIO & Leader, IT Next and CSO Forum.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.com, you agree to our use of cookies.